Hi

Hemant Gokhale wrote:
>       I am new to OJB and looking for some advice on choosing between the
> PersistenceBroker and the ODMG API. Thanks in advance for your help.
>       We are developing a set of simple servlet based applications. And I
> would like to use OJB for persistence. Our scalability requirements are
> modest. I am looking at less than 10 simultaneous requests. I would like to
> keep the code as simple and small as possible. I plan to use OJB in a single
> VM mode (not client server). 
>       I have looked at both the options of using the persistence broker
> directly and using the ODMG API. My initial inclination was to use the ODMG
> API. But on closer inspection I found using the PersistenceBroker directly
> would be simpler and potentially faster. The added advantage of using
> PersistenceBroker is that I can use auto-delete and auto-update features to
> make my code even smaller.
>       The only problem with this approach is the possibility of two
> threads modifying the same object in the object cache. I came up with the
> following strategy to deal with this problem. 
>       Can one of the more experienced people please tell me if this
> approach with work? Or am I on a wrong track?
> 
> *     Create a pool of persistence brokers. The application is expected to
> receive only a few simultaneous requests. So the pool is not expected to
> grow very large. 

There is no need to maintain a pool as the OJB PersistenceBrokerFactory 
does maintain such a pool already!

> *     Inside actionObject.perform() method, before any database
> interaction
> *     get a broker from the pool

That is use PersistenceBrokerFactory to obtain a broker instance.

> *     start a transaction tx
> *     Do all your db access using the tx
> *     At the end of all database interaction (still inside
> actionObject.perform() method)
> *     either commit or abort the tx 
> *     release the broker to the pool.

by calling broker.close()

Yes this makes sense and it is the recommended way to use PB API in a 
multithreaded environment!

cheers,
Thomas

> 
> 
>       Thanks.
> 
>       -Hemant
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> 
> 
> 
> 



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to