ACID on AOP

[marc.fleury]

So julien viet (of cooper nukes fame) came to Atlanta and pitched a silly idea he had while at NIST. I think it would be a great idea.

Essentially we instrument state to version the fields according to transaction demarcation. Meaning

stateChange()

is there a transaction with the calling thread?

if so version and register Synch with TM,
if not version (keep some history if you want for undo) commit new version

at tx demarcation keep new version for commit else keep old version on rollback.

Declaratively you give me an XML file that says

name = blabla
scope = bla
state = acid
history = 3


where the objects remember the state of the past 3 transactions.

transactional interceptor know these by ThreadLocal constructs.

I makes me giggle it is so neat :)

[sanne]

Hi Marc,

O.k. I took your advice and read the whole thread ..., proving I can not only talk, but also listen ;).

Some thoughts about the history option, is the following scenario a possible application: If a collection of objects was comitted by a thread, and none of these where altered or blocked a while later, then in a commit option A scenario one could basically undo the work of a whole committed transaction. And if this is done this transaction disappears from history, making it possible to undo the transaction before.

But ... if one of the objects, say object A, was committed 6 times in the mean time, and all the comitted versions 1,2,3 of this object A are deleted, then all object versions associated with the tx of commit 1,2,3 become useless.

Wouldn't it be sounder to specify a memory limit and start to throw away all objects associated with a transaction, transaction by transaction? Making sure that at least one committed version of each object is maintained, in case of roll backs. The worst case scenario memory wise then becomes when all objects are changed in the same order by the same transaction, then all objects have three versions.

On your line:
'
stateChange()

is there a transaction with the calling thread?

if (transaction==true) version and register Synch with TM,
if (transaction!=true) version (keep some history if you want for undo) commit new version
'

This is written compact, I tried to read it as indicated above. Basically what your saying is that when a transaction is involved with a stateChange()then a local version should be made. On commit this local version becomes the new (non-local) version of the object, on roll back the version of the previous transaction is maintained. If there's no tx, then you could commit directly, but a tx A arriving later on the scene must know that the object has been changed - after - tx A has started, otherwise there would be no isolation. An object version number should then be maintained, with or without associated tx ids. (relevant url: http://www.linuxgazette.com/issue68/mitchell.html)

My head usually begins to spin when there is no commit option A, and there is a multiple version database and a local cache involved.

Regards,

Sanne

[marc.fleury]

The depth of the history is something that is probably best done transaction by transaction you are correct.

I think the algorythm is something we can look at in the near future. Bill works on the interceptors these days.

marcf

[marc.fleury]

I hear bill is done with a pessimistic locking version of the ACID object. Just 2 versions where we keep the new one and the in transaction one.


I like this aspect as there is no one in the industry that actually has it.