Re: Sanity Check on Sharing PersistenceBroker
Robert S. Sfeir wrote: McCaffrey, John G. wrote: You may want to have your getBroker() method return a new instance Yup, 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 2BMail: [EMAIL PROTECTED] SE-182 79 StocksundTel: +46-8-410 064 40 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sanity Check on Sharing PersistenceBroker
McCaffrey, John G. wrote: you may want to create a threaded test to demonstrate concurrent usage. What will happen when you need a transaction to span multiple tables? I do that now, and I don't get that error because I am withing the transaction most of the time. When I am not, I do another begin/end transaction block and I don't get errors. When I get an exception, I always check to see if I am in transaction and do a rollback. Will you get "already in a tranaction" errors? Nope, not so far. You may want to have your getBroker() method return a new instance Yup, 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. R - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sanity Check on Sharing PersistenceBroker
you may want to create a threaded test to demonstrate concurrent usage. What will happen when you need a transaction to span multiple tables? Will you get "already in a tranaction" errors? You may want to have your getBroker() method return a new instance -Original Message- From: Robert S. Sfeir [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 18, 2004 2:35 PM To: OJB Users List Subject: Sanity Check on Sharing PersistenceBroker I'm integrating OJB as tightly as I can with my Struts app, and have written a class which implements the Struts PlugIn API. In that class, when the Struts app starts up, it calls the init() method. In that init method I make some calls to open a DB connection and get a PersistenceBroker. Example follows: private final static void openDB() { try { if( getOjbDBAlias() == null || getOjbDBAlias().length() == 0 ) { throw new PersistenceBrokerException( "OJB Alias Value Cannot be null! Please set it properly before proceeding." ); } LOGGER.log( Level.INFO, "Opening PersistenceBroker Database Instance." ); setBrokerKey( new PBKey( getOjbDBAlias() ) ); setBroker( PersistenceBrokerFactory.createPersistenceBroker( getBrokerKey() ) ); LOGGER.log( Level.FINE, "PersistenceBroker Data Access Layer ready!" ); } catch( PBFactoryException e ) { LOGGER.log( Level.SEVERE, "A PBFactoryException was thrown: " + e.getMessage() + "\n\n" ); } catch( PersistenceBrokerException e ) { LOGGER.log( Level.SEVERE, "An PersistenceBrokerException Occured while opening the database connection: " + e.getMessage() ); } } Easy enough, now once the app is started, there is only one method in the class file which can be used from my DAO layer and that is getBroker(). My question is: Am I doing this as expected, or am I going to get in trouble for using the same broker instance for all DAO calls? The way I would use this persistence broker is, for example: broker.beginTransaction(); final Query query = QueryFactory.newQuery( Acronym.class, crit ); results = ( List ) broker.getCollectionByQuery( query ); broker.commitTransaction(); I don't close the broker of course. Am I going to hit some locking issues here, or is one broker enough to handle getting connections from DB and handle multiple simultaneous calls? Thanks R - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]