db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Max Rydahl Andersen" <...@eos.dk>
Subject Re: [ann] new release 0.9.9
Date Sun, 09 Feb 2003 18:32:06 GMT
> 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?listName=ojb-user@jakarta.apach
e.org&msgNo=2489
http://archives.apache.org/eyebrowse/ReadMsg?listName=ojb-user@jakarta.apach
e.org&msgId=471441
http://archives.apache.org/eyebrowse/ReadMsg?listName=ojb-user@jakarta.apach
e.org&msgId=479655
http://archives.apache.org/eyebrowse/ReadMsg?listName=ojb-user@jakarta.apach
e.org&msgId=468817
http://archives.apache.org/eyebrowse/ReadMsg?listName=ojb-user@jakarta.apach
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:max@eos.dk]
> Sent: Saturday, February 08, 2003 9:36 AM
> To: OJB Users List; thma@apache.org; 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" <thma32@web.de>
> To: "OJB Developers List" <ojb-dev@db.apache.org>; "OJB Users List"
> <ojb-user@db.apache.org>
> 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: ojb-user-unsubscribe@db.apache.org
> > For additional commands, e-mail: ojb-user-help@db.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>


Mime
View raw message