Hi,
I've got a question/theorem about the threadsafety of transactions
(TransactionImpl).
Suppose I have an application, instantiating one and only one persistence
broker using the OJB ODMG API ( using classes Implemenatation and Database).
This application may start other threads passing a reference to the
Implementation instance along to the new threads, the threads use this
reference to persist objects (this case is viable in a situation where you
have a scheduler, and jobs started by the scheduler and you have an embedded
HSQL database that allows only one connection open at any time, so only one
broker can be instantiated).
All threads start transactions and manage them using TransactionImpl. It is
possible that they all commit their respective transactions at the same
time. This is fine, they have their own TransactionImpl instance, so it's
possible and shouldn't be a probleme. But, all these TransactionImpl
instances have been instantiated using the same broker reference. So
underneath, they all reference the same PersistenceBroker instance.
Commiting a transaction, the TransactionImpl instance execute the following
code (actual code in ObjectEvelopeTable, method:commit, called from
TransactionImpl, method:doCommitOnObjects )
if(!broker.isInTransaction()) broker.beginTransaction();
This is false for the first thread in line, so it begins a transaction, true
for the other threads so they simply continue without beginning a new
transaction, in fact this results in the other treads joining the same
transaction started by the first thread at PB API level. What we observe is
that multiple stand alone OJB ODMG transactions are getting mixed up/joined
in one low level PB API transaction. Finally the first thread to commit,
commits the opened PB API transaction, committing it's own persistence
operations in it's OJB ODMG transaction, but also the persistence operations
of the other threads that, by that time, have been added to the shared PB
API transaction. After which the OJB ODMG transactions of the other threads
are closed, they are partially committed, and pending persistence operations
of these transactions are not executed, but the transaction in which they
occur is corrupted.
Because ODMG transactions may share a persistence broker instance, to
prevent these kind of concurrency problems, the transactions should acquire
exclusive locks on the broker before the committal of ODMG transactions and
release the lock after the commit/abort.
Right now, TransactionImpl does not look to be threadsave to me!
Is the above correct, or am I missing things?
Roger Janssen
iBanx - www.ibanx.nl <http://www.ibanx.nl>
*************************************************************************
The information contained in this communication is confidential and is
intended solely for the use of the individual or entity to whom it is
addressed.You should not copy, disclose or distribute this communication
without the authority of iBanx bv. iBanx bv is neither liable for
the proper and complete transmission of the information has been maintained
nor that the communication is free of viruses, interceptions or interference.
If you are not the intended recipient of this communication please return
the communication to the sender and delete and destroy all copies.
