Re: how to clear cache
Armin Waibel <[email protected]> Wed, 26 Sep 2007 12:20:00 +0200
| Newsgroups | gmane.comp.jakarta.ojb.user |
|---|---|
| Message-ID | <[email protected]> |
Armin Waibel wrote: > (...and it's correct) But if you want to take advantage from a session > cache on multi findByPrimaryKey calls of the same id or you have to > store hundreds of objects it's a bit a "performance anti pattern" to > close the PB instance on each method call (this evicts the session > cache) or to perform the tx-cycle for each object (this way you can't > rollback the whole operation if something went wrong). > > Think it would be useful to allow some kind of PB "inject" in the DAO > implementation (direct or indirect via ServiceLocator) and the DAO never > close the "inject" PB instance. > On insert, update, delete the DAO implementation: > -force a PB-tx (if not running start one and commit/rollback, if running > don't commit at the end) > -or throw an exception if no tx is running on the "inject" PB (more > transparent). > But never allow object modification without a running tx. > Seems I was too late. As I can see you post a similar suggestion a few minutes before my post. Armin > regards, > Armin > >> >> Anyway remember that Mandragora works with the interface DAO, and if you >> think in a better way can be done, >> we could write an other DAO implementation, and it is used just >> changing the >> correspondent entry in Mandragora.properties >> >> Regards >> >> Alessandro >> >> On 9/25/07, Hans Novak <[email protected]> wrote: >>> >>> >>>> PersistenceBroker.clearCache(); >>>> to evict the whole cache >>> yes, this works, but will increase the database access a lot. >>> You speaks about the possibility, that ojb and mandragora can use the >>> same PB ... how ? >>> I have a dao class, with the broker. >>> This broker is private and will not used in any other classes !? >>> >>> The other way is to clear only the obj with a oid - but what for oid ? >>> (a uniqe id from a filed in database ?) >>> But this operation willincrase the access to the db too.... >>> The better way is to use the same broker, i think. >>> >>> Hans >>> >>> >>> --------------------------------------------------------------------- >>> 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] > >