RMI and DB Transactions

[Alisa Jackson]

We have an application (java on top of oracle) which is primarily
accessed through RMI. A customer asked to make the API transactional
so that they would have the explicit control over
start/commit/rollback of any changes our app does to the database.

What are some standard approaches for doing this? The only obvious
thing seems to be to expose some integer transactionId as an argument
to every method of the API and then pass that transactionId from the
client to the server and down the call stack until it gets to the
point where the actual DB operation is occurring and then use the
Connection associated with that transactionId.

This seems ugly on many levels. One is that the client needs to pass
around this transactionId, and even worse all the internal interfaces
need to be modified to pass around the transactionId between methods.

Do you have any better suggestions on how to address this? The project
has some time so we want to have a proper solution for it, preferrably
one that does not require purchasing third party software.

Thanks,
- alisa

[rkm]

I believe JDO (Java Data Objects) would provide the
transactional interface you want. Never used it myself,
just read about it.
Alisa Jackson wrote:

We have an application (java on top of oracle) which is primarily
accessed through RMI. A customer asked to make the API transactional
so that they would have the explicit control over
start/commit/rollback of any changes our app does to the database.

What are some standard approaches for doing this? The only obvious
thing seems to be to expose some integer transactionId as an argument
to every method of the API and then pass that transactionId from the
client to the server and down the call stack until it gets to the
point where the actual DB operation is occurring and then use the
Connection associated with that transactionId.

This seems ugly on many levels. One is that the client needs to pass
around this transactionId, and even worse all the internal interfaces
need to be modified to pass around the transactionId between methods.

Do you have any better suggestions on how to address this? The project
has some time so we want to have a proper solution for it, preferrably
one that does not require purchasing third party software.

Thanks,
- alisa

[John C. Bollinger]

Alisa Jackson wrote:

We have an application (java on top of oracle) which is primarily
accessed through RMI. A customer asked to make the API transactional
so that they would have the explicit control over
start/commit/rollback of any changes our app does to the database.

What are some standard approaches for doing this? The only obvious
thing seems to be to expose some integer transactionId as an argument
to every method of the API and then pass that transactionId from the
client to the server and down the call stack until it gets to the
point where the actual DB operation is occurring and then use the
Connection associated with that transactionId.

This seems ugly on many levels. One is that the client needs to pass
around this transactionId, and even worse all the internal interfaces
need to be modified to pass around the transactionId between methods.

Do you have any better suggestions on how to address this? The project
has some time so we want to have a proper solution for it, preferrably
one that does not require purchasing third party software.

If the API needs to be transactional then there is no alternative to
keeping a transaction context on the client side that the client must
communicate back to the server side with each operation. That
transaction context need not be represented by an integer, however;
indeed, it is likely that you would find many reasons to use a suitable
object for the purpose. Moreover, it is not necessarilly the case that
the client must be charged with managing the transaction context
directly, and in fact it is probably not wise to do it that way. Look
at JDBC, for instance: it is transactional, but the transaction context
is internal to each Connection.

If you want to model after JDBC, then you would want a client-side
object through which communication with the server is performed. (This
is an analog of a JDBC Connection.) You may already have a suitable
object in your design, but if not then creating one may have more
advantages than just transaction support.
John Bollinger
jo******@indiana.edu