Start a Conversation

Unsolved

This post is more than 5 years old

A

2101

March 17th, 2011 02:00

OID interface and transaction safety

I'm concerned that using the Atmos object interface, which is the more "performant" interface, is inherently not transaction safe.

The user guide says: " The application layer might need to persist OIDs and perform a translation for an application’s end users (if necessary)."

However, consider the case where an application instructs Atmos to create an object, then, before the OID is successfully persisted by the application, the system crashes.

The result would be an unreferenced, "dangling" object, which can never be accessed again.

Is there any way to use the object interface in a transaction safe way?

5 Posts

March 17th, 2011 07:00

Raj,

Thanks for your quick response .

I'm afraid that the OID leakage problem still exists if the system fails in step 3 - the object with this OID still exists (small as it may be), is no longer reachable and will never be deleted  - so strictly speaking, it is still not transaction safe.

Also, I think that performing two operations / round trips per insert might mitigate the performance advantages of using OIDs.

Ideally, I would envision Armos allowing the application to specify an OID while creating the object. Is this possible?

222 Posts

March 17th, 2011 07:00

It's certainly possible that failure could occur somewhere within the process of creating an object and receiving/persisting an object_id.

Here's a potential way to address this:

1.  Your application creates an initial object with a very small amount of data

2.  Your app receives an object_id from Atmos in response

3.  If it receives the object_id and successfully persists it

4.  Add data to the object specifying the object_id using update_object (which does byte range updates using the HTTP range header)

So you can effectively mitigate the potential for failure by only writing to the object if you know that it exists on the server.

You can also address object durability by creating erasure coded objects.

Let me know if this helps --- happy to address other questions or issues.


Raj

222 Posts

March 17th, 2011 12:00

If your application creates the initial small object, persists the ID, and then starts writing to the object but fails then you can still access the object by its OID.  So it's not necessarily unreachable and you can delete it.  You could potentially use a listable tag (temporarily even perhaps) to track the particular object and refer to the listable tag to access it afterward.

You can use the namespace interface to be able to name your own objects, but you would have to manage the layout, etc.  The performance difference between the namespace and object interface are not an order of magnitude in nature --- your app and users would likely not even notice the slight difference.  We have many customers and partners that use namespace and are quite happy with the results.

I can't provide too many specifics at this point, but I can say that we are working on enhancements that would allow you to create your own OID.

5 Posts

March 20th, 2011 05:00

Thank you.

No Events found!

Top