db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tobr...@transolutions.net (O'brien, Tim)
Subject Outdated doc on site
Date Mon, 10 Feb 2003 06:38:36 GMT
The documentation available on the OJB website seems to be stale compared to
the CVS repository.  I'm looking at db-ojb/xdocs/tutorial1.xml and
http://db.apache.org/ojb/tutorial1.html, doesn't seem like the corrections
from November are on the site.

Also, is there any interest in moving documentation over to Forrest?

--------
Tim O'Brien 


> -----Original Message-----
> From: thma32@web.de [mailto:thma32@web.de] 
> Sent: Sunday, February 09, 2003 2:49 PM
> To: OJB Developers List
> Subject: Re: [ann] new release 0.9.9
> 
> 
> Hi again Max,
> 
> Max Rydahl Andersen wrote:
> > ----- 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"!
> 
> OK. has been checked in into CVS ten minutes ago!
> 
> > 
> >>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).
> 
> It's *not* a design issue. As my coding sprint demonstrates: A per tx 
> cache can be built within ten minutes.
> 
> > 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 :(
> > 
> 
> SOme users want a global cache.
> others want a per tx cache.
> Some users don't want any caching at all.
> 
> OJB can handle all these requirements!
> If something is not yet implemented it can be plugged in as a user 
> defined component.
> 
> 
> > 
> >>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 :)
> >
> 
> So simply go for PB!
> 
> > 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.
> 
> PB can do this for you.
> 
> > 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)
> 
> Maybe I'm getting OT here, but dict.leo.org translates "hibernate" as 
> "holding winter sleep".
> At dict.leo.org you'll find all kind of cool names for 
> software tools. 
> What about "trypanosomiasis" 
> (http://dict.leo.org/?p=TGGT..&search=Trypanosomiasis) ;-)
> 
> cheers,
> Thomas
> 
> > /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
> > 
> > 
> 
> 
> 
> ---------------------------------------------------------------------
> 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