Hi Martin,

with latest version from CVS (upcoming next release) it is possible to define the ObjectCache per class/per jdbc-connection (and a default
cache in OJB.properties).
More info you can find in the ObjectCache documentation of CVS version.
Build docs with
bin\build.bat htmldoc
or
bin/build.sh htmldoc


generated docs are in db-ojb/target/doc

regards,
Armin

Martin Kalén wrote:
Greetings OJB-users,

I am currently looking into a viable solution for the following problem:

I have two different connection-descriptors (and thus two different jcdAliases, let's call them "ALIAS1" and "ALIAS2") pointing to the same Oracle database but logged in with two different users (let's call them "USER1" and "USER2"). This is like two different data contexts with the same DDL.

In the OJB repository a certain class ("A") is mapped and loaded with different PersistenceBrokers from any of these two connection-descriptors.

The primary key definition for the class is a single column with a unique ID ("ID").

In the following situation:
USER1 (jcdAlias=ALIAS1): ID=0, other_field='foo'
USER2 (jcdAlias=ALIAS2): ID=0, other_field='bar'

If I use the OJB default global cache-implementation and do a getObjectByQuery for class A from a broker from connection-pool with ALIAS1, the Identity-definition in OJB will cause the PersistenceBroker to ignore reloading class A when I do a getObjectByQuery for class A from a broker from connection-pool with ALIAS2. There will be a cache-hit and other_field='foo', also for ALIAS2.

If I turn off caching or use per-broker cache then the second PB-request will of course load other_field='bar' from ALIAS2 (which is what I want in this case).


In my use-case the per-broker cache is pretty useless and is similar in performance to no cache at all, so what I would like is something in between; a "per-jcdAlias cache" or rather "per-connection-pool cache".


This would be sort of redefining Identity to be a composite of current definition (all persistent fields with primary-key="true") and jcdAlias from the connection-pool.

Any thoughts about this? Has anyone tried a similar solution?

TIA,
 Martin




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



Reply via email to