Transaction manager (Objectstore)

[sid derra]

Hi

I currnently am working on a project which is supposed to run with an
Objectstore (actually PSE-Pro) DB-backend.
Now i have a little question to the group: Would any of you like to share a
design pattern or code snippet for a transaction manager class? It should
take care of the access to the Objectstore-ressources (locks, threads,...)
to prevent exceptions and allow serializability. Google couldnt really give
me all too many useful results, which is why i'd like to ask you guys.

Thanks a bunch in advance
sid

x-posted

 

[Robert Klemme]

Hi

I currnently am working on a project which is supposed to run with an
Objectstore (actually PSE-Pro) DB-backend.
Now i have a little question to the group: Would any of you like to
share a design pattern or code snippet for a transaction manager
class? It should take care of the access to the
Objectstore-ressources (locks, threads,...) to prevent exceptions and
allow serializability. Google couldnt really give me all too many
useful results, which is why i'd like to ask you guys.

Thanks a bunch in advance
sid

ObjectStore is a page server. AFAIK they do locking on page level. You
would have to instrument / consider that. Depending on how much
concurrency you want smart placing of instances on pages / segments might
be enough.

Kind regards

robert

 

[Wibble]

ObjectStore is a page server. AFAIK they do locking on page level. You
would have to instrument / consider that. Depending on how much
concurrency you want smart placing of instances on pages / segments might
be enough.

Kind regards

robert

I dont know anything about objectStore but I have built transaction
managers.

class ConnectionManager {
public static ConnectionManager getSingleton();
public Connection getNamedConnection(String name);
public void beginTransaction();
public void endTransaction(boolean commitp);
}
ConnectionManager.getSingleton().beginTransaction();
boolean commitp = false;
try {
Connection conn =
ConnectionManager.getSingleton().getNamedConnection("odiool");
/* do stuff */
commitp = true;
}
finally {
// commitp is false on exception, so votes to rollback.
ConnectionManager.getSingleton().endTransaction(commitp);
}



Store the transaction object in a thread local. beginTransaction
increments a count so the begin/ends can nest. endTransaction
decrements the counter. When it goes to zero, if any endTransaction
or any Connection voted against commit, then rollback.

getNamedConnection ensures that a connection from the named pool
lives in the transaction. All connections in the transaction
are committed together or rolled back together in a two-phase
commit. Theres some risk that the commits fail, but its about
as good as you can do without a real XA transaction.