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 19:37:12 GMT

----- Original Message -----
From: "Raghuram Rajah" <raghuram.rajah@s1.com>
To: "'OJB Developers List'" <ojb-dev@db.apache.org>; "OJB Users List"
<ojb-user@db.apache.org>; <thma@apache.org>
Sent: Sunday, February 09, 2003 7:50 PM
Subject: RE: [ann] new release 0.9.9


> 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.

See - here's the word locking! I (and any other for that matter) should not
need to use locking to have transaction isolation in a persistence layer
unless it is strictly needed by the app!
The database is very capable in handling this! And in a persistence layer
such as OJB's PB it is quite easy to solve: Simply have one cache per
"unit-of-work"!

> A non-locking approach will not fully solve the transaction isolation
problem.

No, but OJB's design put's a very heavy burden on their users that is
unnecessary (IMHO).
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 :(

> 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.

And ODMG is a way to much complicated API to use IMHO :)

ODMG's (and hence OJB's) pessimistic locking strategy is simply not good
enough. I want an optimistic locking
strategy with OPTIONAL pessimistic locking if needed.

So, I guess i'll stick with my hibernate (which core has thread safe (and
efficient) access to loaded objects and does not require locking - but it
still does provide locking as an option)

/max


> Raghu.
>
>
> -----Original Message-----
> From: Max Rydahl Andersen [mailto:max@eos.dk]
> Sent: Sunday, February 09, 2003 1:32 PM
> To: OJB Users List; 'OJB Developers List'; thma@apache.org
> 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?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
> >
> >
>
>
> ---------------------------------------------------------------------
> 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-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>


Mime
View raw message