db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mahler <thm...@web.de>
Subject Re: [ann] new release 0.9.9
Date Sun, 16 Feb 2003 11:23:53 GMT
Hi again Max,

Max Rydahl Andersen wrote:
> It look ok and will work in most cases - still don't like solutions that
> depends on threadlocal data/state
> to be available. e.g. the current implementation will "demand" I only use
> one PB per unit-of-work at one time.
> (A requirement I actually have had when doing some "batch"-work..).

The solution I built is not one cache per thread. It is also not one 
cache per broker transaction. It is one cache per broker.

A broker can handle only one transaction at a time. So the solution is 
one cache per tx in effect if you do a broker.clearCache() call as the 
first call in a new broker tx.

>>>No, but OJB's design put's a very heavy burden on their users that is
>>>unnecessary (IMHO).
>>It's *not* a design issue. As my coding sprint demonstrates: A per tx
>>cache can be built within ten minutes.
> A per thread context cache can be built, not per transaction cache :)

Armin and I are currently working on an improvement of the broker / 
cache interaction that will allow a clean per tx cache.

>>>The worst thing is that if the developer is not aware of the problems
> with
>>>the PB api (and the PB api is actually suggested as
>>>an sufficient API for most applications!). The thread problems WILLoccur
> at
>>>some point in an applicaiton with multiple threads accessing the same
> data
>>>and you will not be warned about it - no exception, no warning, no
> nothing -
>>>just an database with invalid data, and you will never know what hit you
> :(
>>SOme users want a global cache.
>>others want a per tx cache.
>>Some users don't want any caching at all.
>>OJB can handle all these requirements!
>>If something is not yet implemented it can be plugged in as a user
>>defined component.
> And I like that about OJB, just don't like that the design relies on
> threadlocal state instead
> of inner-object state (e.g. cache stored optionally per PB)

It's done that way: each broker holds a reference to its dedicated 
cache! It's only the CacheFactory that currently serves all brokers with 
the same singleton cache instance. Could easily be changed.

But with the upcoming changes Armin and I are planning this won't be 


View raw message