Sounds great!

I'll look into it as soon as I'll be back at my office (2 days from now).

/max

----- Original Message -----
From: "Thomas Mahler" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Sunday, February 09, 2003 9:18 PM
Subject: Re: [ann] new release 0.9.9


> Hi again Max,
>
> Good news for you!
> I just checked in the implementation outlined in my last post.
> SO you can just sit back and enJoy!
>
> Have a look at org.apache.ojb.broker.cache.ObjectCachePerBrokerImpl.
>
> cheers,
> Thomas
>
>
> Thomas Mahler wrote:
> > Hi again Max,
> >
> > 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!
> >>
> >> /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]
> >
> >
>
>
>
> ---------------------------------------------------------------------
> 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]

Reply via email to