We have not worked in this area in the last months.
If you want to have a cache per broker transaction proceed as follows:
1. implement the interface ObjectCache with a hierarchical cache.
this implementation will hold a table mapping broker transactions to "real" cache instances.
All access to the ObjectCache interface will be delegated to the actual cache instance associated with a given transaction.
There is some API for broker to thread mapping, so this implementation will not take more than an hours work!
2. post your implementation to the list. We will review it and integrate it into the code base.
cheers,
Thomas
Max Rydahl Andersen wrote:
Hey Max, What do you mean by "threadsafe handling of the objects without relying on locking"? Could you give an example.OJB's current design only provides ONE object cache per VM,. not one per "session"/"unit-of-work". Thus, if you are NOT using locks (e.g. just using the core PB-api) then you will not be able to have thread-safe handling of the persistent objects. If thread 1 reads ObjectA and thread 2 reads ObjectA then they will not get two seperate objects - they will get the exact same instance! Thus it is indeterminate which threads changes that will be saved! This is a wellknown and OLD problem as the following threads will show you (and i've only found the threads that I've written about this problem) http://archives.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED] e.org&msgNo=2489 http://archives.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED] e.org&msgId=471441 http://archives.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED] e.org&msgId=479655 http://archives.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED] e.org&msgId=468817 http://archives.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED] e.org&msgId=502638 OJB's core API i simply not threadsafe and is thus not usable in applications which have multiple threads (read e.g. J2EE servers - both web and session beans will potentially be unsafe if one just uses the core API without the object locking mechanisms provided with ODMG). And using ODMG is for me not an option as I do not need the overhead and complexity the ODMG "builds up". It is usefull for some cases, but I do not want object transactions etc. This problem is the reason why I stopped using OJB and starting looking at other persistence layers which does not require usage of actual locking of objects inside a single VM. (examples of this are Hibernate, Jaxor et.al.) And as I wrote in one of those reference threads: This is not in any way a "OJB does not work"-speech, I am just stating the facts regarding OJB's current design regarding the object cache. I know there is work going on with the OTM (Object transaction manager) which might remove this thread-unsafe'ness, but that work has been going on for a looong time now :( And I've asked this question all the times a new release announcment has been made to see if this core feature has been provided/added in the newest release. Note: Some people have provided an EmptyCache implementation so the same instances will not be returned to the threads - this removes the above problem, but with an EmptyCache one removes OJB's possibility to resolve circular references (result some times in an StackOverFlow error) and provide =='nes for entities loaded multiple times. Please correct me if this is in anyway wrong! /maxRaghu. -----Original Message----- From: Max Rydahl Andersen [mailto:[EMAIL PROTECTED]] Sent: Saturday, February 08, 2003 9:36 AM To: OJB Users List; [EMAIL PROTECTED]; OJB Developers List Subject: Re: [ann] new release 0.9.9 Any light in the tunnel for threadsafe handling of the objects without relying on locking them via ODMG ? /max ----- Original Message ----- From: "Thomas Mahler" <[EMAIL PROTECTED]> To: "OJB Developers List" <[EMAIL PROTECTED]>; "OJB Users List" <[EMAIL PROTECTED]> Sent: Friday, February 07, 2003 11:48 PM Subject: [ann] new release 0.9.9Hi all, I've just assembled the latest release of our favourite software. Thanks to all who helped to get this done! From the release notes: ======================================================================== ObJectRelationalBridge -- Bridging Java Objects and Relational Databases ======================================================================== ObJectRelationalBridge (OJB) is an Object/Relational mapping tool that provides transparent transactional persistence for Java Objects against relational databases. OJB supports ODMG and JDO. --------------------------------------------------------------------- Release 0.9.9 --------------------------------------------------------------------- NEW FEATURES: - With this release we are feature complete for the 1.0 release! For 1.0 you should not expect more features to be added. CHANGES: - Metadata handling was improved. The persistent object metadata is decoupled from the connection metadata. - Multiple database support was simplified. Now you only need one repository file and it is allowed to define several jdbc-connection-descriptors in the repository file. - In the PBKey we now use an alias name (and user/password) to match the connection (jdbc-connection-descriptor), instead using the path to the repository file. - Remove the "max. connections in pool" property from OJB.properties, this could be done separate for each database in the repository file using the connection-pool element. - Move sequence manager configuration from OJB.properties into the repository file (see sequence-manager element in repository.dtd). Now it's possible to define a separate sequence manager for each jdbc-connection-descriptor. - Refactored sequence package, better support for database based id gerneration. - The connection factory implementations using connection pooling (ConnectionFactoryDBCPImpl, ConnectionFactoryPooledImpl) now support a 'validationQuery' to check if the returned pooled connection is valid. - Make JdbcAccess, ConnectionManager, StatementManager pluggable via setting in OJB.properties - PersistenceBroker api changes of methods used in kernel getExtentClass ---> getTopLevelClass getConnectionManager --> serviceConnectionManager getStatementManager --> serviceStatementManager getUniqueXXX methods removed ---> use serviceSequenceManager instead add new method removeListener - Improve the OJB performance test suite. Add a simple test framework to allow comparison of OJB with other O/R mapping tools. BUG FIXES: - tons of bug fixes More information is available at http://db.apache.org/ojb I hope you enjoy the new release, cheers, Thomas --------------------------------------------------------------------- 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] --------------------------------------------------------------------- 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
