db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mahler Thomas <thomas.mah...@itellium.com>
Subject AW: Outdated doc on site
Date Thu, 13 Feb 2003 12:11:59 GMT
Hi all,

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

I've contacted Jason last weekend to 
1. update the website with a tarball I posted to him.
2. give me sufficient karma to do website updates myself.

Jason promised to help with both issues.
So I hope we'll see a website update within the next few days.

When OJB was still at sourceforge I updated the website with each new
release and if necessary also between releases.
Once I got access to update the site I will do it the same way.

> > Also, is there any interest in moving documentation over to Forrest?
> 
> This sounds very interesting!
> You are right, it's very frustrating see docs from
> version 0.9.4 (2002/08!!) on the website.
> 
> I'm interested in all solutions bring the actual
> documentation up.

Currently there is a ant target available that generates a complete website.
maven xdoc can be used to generate a jakarta style website.

IMO it's not a question of tooling. We have all tools to generate a decent
website.
The problem is that it was not possible to get write permission for me at
Jakarta and that I don't have write permission at db.apache.org yet.

I hope that this can be solved soon.

cheers,
thomas

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