Hey Max, Ah! Transaction Isolation. PB API is the O/R kernel of OJB and hence does not and should not provide functions like Transaction Isolation. If you use the PB API, then the expectation is that you will externally manage such add-on functions. If you like to use functions like transaction-isolation then ODMG API is what you need to use. The overhead you mention is merely the code to take care of transaction isolation, through locking. A non-locking approach will not fully solve the transaction isolation problem.
I understand that with ODMG has some glitches and that OTM, which was supposed to fix this, is slow. I am at fault for the latter. I had got very busy in the last quarter of the previous year. There is some renewed enthusiaism in the past few weeks and believe me some real solid work is going on in that direction. In the meantime, ODMG is the direction I would advise you to take. Raghu. -----Original Message----- From: Max Rydahl Andersen [mailto:[EMAIL PROTECTED]] Sent: Sunday, February 09, 2003 1:32 PM To: OJB Users List; 'OJB Developers List'; [EMAIL PROTECTED] Subject: Re: [ann] new release 0.9.9 > 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! /max > Raghu. > > -----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.9 > > > > Hi 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]
