[Objectbridge-developers] ODMG Transaction Management

[<tho...@it...>]

Hi David, Hi all,

During the last weeks I've been working on an implementation for ODMG
persistent collections.
My first aim was a DList implementation which is working quite well already.
During this work I found some bugs in the transaction mangement classes and
also some code doubling and
incoherent pieces of code. I'd like to improve this basic functionlity
before working on the other
collection classes.

I like your idea of TransactionWrapper objects. They are a great help in
building event mechanisms and
holding shadow copies for restoring objects on a tx.abort().
But I see a problem which cannot be solved easily.
There are three concrete subclasses InsertTransactionWrapper,
DeleteTransactionWrapper,
UpdateTransactionWrapper. Let's assume mark an object for update, that is we
place it in a
UpdateTransactionWrapper. Now assume the client app wants to mark the same
object for deletion.
What will happen? I do not see any solution for this in your code.
Doing such a state transition using your classes will need something like
the following:
- remove the UpdateTransactionWrapper from the TransactionImpl's
updateObjectList.
- create a DeleteTransctionWrapper object
- place it in the deleteObjectList

Of course this it's possible to implement this functionality but involves a
lot of searching through
the getAllObjects() list.
Also each state transition involves discarding one wrapper and creating a
new one.

I addressed these state transitions explicitly in the ModificationState and
its subclasses.
The ModificationState subclasses are also responsible for commit(), abort()
and checkpoint() by
implementing the adequate persistence operations.
(These classes apply the state pattern and the command pattern.)

A related problem: you did not implement update, insert and delete logic in
your wrapper objects but
delegate this to my ObjectStateTable. The delegation as such is not a
problem, but
for each object under transaction management we now need 1
ObjectTransactionWrapper and
1 ObjectModification object.

Here is my solution:
Let's merge the classes ObjectTransactionWrapper and ObjectModification:
1. Remove subclasses of ObjectTransactionWrapper.
2. make ObjectTransactionWrapper concrete
3. add an attribute state of type ModificationState.
4. get rid of my ObjectModification class.
5. maintain only one list of TransactionWrapper table in the TransactionImpl

If you don't have any objections I'd like to implement this design in the
next days.
Please tell me what you think and tell me if you have further suggestions.


thank you,

Thomas