Hi Roger, ----- Original Message ----- From: "Janssen, Roger" <[EMAIL PROTECTED]> To: "OJB User List (E-mail)" <[EMAIL PROTECTED]> Sent: Monday, October 21, 2002 10:29 AM Subject: Theorem about TransactionImpl not being threadsave
> 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 ?? really? > , so only one broker can be instantiated). No, only one connection could be instantiated (if hsql assumption was right). PB (pool) was decoupled from the connection (pool). So it's possible get differnet PB instances at any time (till the maxActive limit was reached - see OJB.properties). > > 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. No, all tx using different PB instances. See TransactionImpl#getBroker() method. Each tx use exactly one PB instance, but every tx use a different one. When commit the tx, the PB instance obtain a connection do all persistent operations an return (close) the connection. Assumed we only have one connection, then other tx have to wait for commit or failed if they could not found a connection. See OJB.properties PersistenceBrokerFactory pool ConnectionFactory / Default ConnectionPool >So > underneath, they all reference the same PersistenceBroker instance. No. ..... ..... > Right now, TransactionImpl does not look to be threadsave to me! > > Is the above correct, or am I missing things? Many things you described, did not reflect the behaviour of OJB. Thus I allege ODMG api implementation was threadsafe (maybe I have overlooked something - correct me if I'm wrong ;-). Full version of OJB shipped with a stress test were 10 threads at the same time handling 2000 objects per thread (store, fetch, delete each object) and this test passed well (call bin\build.bat performance2). HTH regards, Armin > > 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. > -- To unsubscribe, e-mail: <mailto:ojb-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:ojb-user-help@;jakarta.apache.org>
