McCaffrey, John G. wrote:You may want to have your getBroker() method return a new instanceYup, this is why I'm asking to see if the gurus on this list know whether this is necessary of it PB is smart enough to deal with it correctly.
If you by "simultaneous" mean that multiple threads will use the same PB instance, I would definately recommend that your DAO layer implements one method for getting a broker and another one for releasing it after use. The underlying JDBC connection-pool will take care of pooling DB-connections even if you change to this "short-lived" PersistenceBroker-strategy.
There are no synchronizations in the default PB implementation, so you would have a race condition that could hit broker.beginTransaction() multiple times before commit/abort.
Also, with default cache-strategies and a share broker: objects in the cache updated by store-calls from one thread will be visible by other threads even before commit (sic!). This can of course be changed by turning off the cache or changing cache strategy. Note that multiple brokers as per my suggestion do not change this, you need per-broker-cache if you don't like this behaviour. (A two-level cache has been in the works for some time, and my bet is that you will see one in OJB 1.1).
However; I don't consider myself as one of the gurus so feel free to disregard all of the above. :-D
-- Martin Kalén Curalia AB Web: http://www.curalia.se Orrspelsvägen 2B Mail: [EMAIL PROTECTED] SE-182 79 Stocksund Tel: +46-8-410 064 40
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
