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 20:17:48 GMT
I unfortunately cannot find the time to provide this currently.
I tried to provide that functionallity waay back (if you can remember) - but
here
I came short as it would require an API change in the broker to be able to
assign
a cache per broker instead of accessing the cache via a
Singleton.getInstance() call.

As a sidenote: Having a broker per thread is not "enough" as there is no
need to have an
 bound on how many concurrent brokers a thread can use (IMHO).

/max

----- Original Message -----
From: "Max Rydahl Andersen" <max@eos.dk>
To: "OJB Developers List" <ojb-dev@db.apache.org>
Cc: "OJB Users List" <ojb-user@db.apache.org>
Sent: Sunday, February 09, 2003 8:37 PM
Subject: Re: [ann] new release 0.9.9


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