Re: Sanity Check on Sharing PersistenceBroker

[Martin Kalén]

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.]

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]

Re: Sanity Check on Sharing PersistenceBroker

[Robert S. Sfeir]

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]