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