Home > Archive > Java Help > June 2005 > Transaction manager (Objectstore)
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Transaction manager (Objectstore)
|
|
| sid derra 2005-06-07, 4:03 pm |
| 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 2005-06-07, 4:03 pm |
| sid derra wrote:
> 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 2005-06-08, 4:01 am |
| Robert Klemme wrote:
> sid derra wrote:
>
>
>
> 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("odi:pool");
/* 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.
|
|
|
|
|