geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Braeuchi <>
Subject Re: [persistence] Some thoughts regarding CMP and JDO
Date Fri, 08 Aug 2003 22:44:22 GMT
+1 to what matthew and rahu wrote.

just my 0.02 CHF.

Raghuram Rajah wrote:

>+1 to all the Matt mentions. I personally don't see the point in
>re-inventing the wheel. Besides, using an existing (and sound) persistence
>manager like OJB would give Geronimo good traction both in feature-set and
>time-to-market. Not to mention the opportunities that belonging to Apache
>family would bring (things that immedietely come to my mind are potential
>for more stronger interaction between the Geronimo JTS and OJB OTM).
>If the Geronimo team still strongly believes in getting into the business of
>writing O/R mapping frameworks, atleast an abstraction is due there. Just
>so, the native persistence manager could be swapped for either OJB (or even
>Hibernate, Toplink, Cocobase or whatever). Also, an early exposure to this
>abstraction could let OJB team to fill the gap. 
>Further, bringing in another persistence service within the apache family
>(Torque vs. OJB vs. Geronimo-persistence), makes me wonder where we are
>-----Original Message-----
>From: Matthew Baird []
>Sent: Friday, August 08, 2003 12:16 PM
>To: OJB Developers List
>Subject: RE: [persistence] Some thoughts regarding CMP and JDO
>If I'm reading this correctly:
>1. Version 1.0 is going to try and support several back ends other than just
>2. You've already started to re-implement the persistence mechanisms.
>3. Using the "front ends" of other Persistence frameworks equates to roughly
>supporting their general API's and probably more specifically their Query
>API's, however all real work will be done by the new persistence code on the
>back end.
>4. You are open to integrating code/thoughts from several different
>persistence mechanisms into the Geronimo-specific implementation.
>Feel free to correct me if I'm wrong on this one.
>Based on those assumptions:
>1. This is a pretty huge project with a rather large featureset. Supporting
>non-relational backend stores is a major PITA without bringing a lot of
>2. Do we need yet another persistence framework? Most people reading this
>have been involved in building persistence frameworks in the past and
>understand the scope. Is there a solid reason for not choosing something
>that is out there and just using that? At the very least, it's a huge head
>start on the project which allows more time to be spent building aspects of
>the container that don't already exist.
>3. Isn't one of the Jakarta criteria "Alignment with existing Apache
>4. Perhaps there is some show-stopper in the OJB design that will not lend
>itself to being used as the persistence layer. Although it sounds like the
>designs are aligned.
>It really comes down to a build vs. buy, and in this case the price is $0.00
>so it seems to be a no-brainer. Why not turn the proposal upside down: Use
>OJB as the default back-end persistence mechanism and lend your CMP 2.0
>experience towards making OJB a better project as well?
>	-----Original Message----- 
>	From: Dain Sundstrom [] 
>	Sent: Thu 8/7/2003 9:34 AM 
>	To: Mahler Thomas 
>	Cc:; OJB Developers List (E-Mail) 
>	Subject: Re: [persistence] Some thoughts regarding CMP and JDO
>	Hello Thomas (and the rest of the OJB team),
>	Jeremy Boynes and I (and a few others) wrote the CMP 2.0
>	in JBoss, and we have been working on the persistence code in the
>	initial Geronimo code base.
>	There is some code right now (a compiler and sql generator) and a
>	fairly extensive design, but it looks like we have similar designs. 
>	The design is fairly simple from the high level.  We will support
>	several front end layers simultaneously at runtime (CMP, JDO, maybe
>	Hibernate, heck maybe SQL).   The job of the front end layer is to
>	handle the life-cycle and callbacks required by the related
>	specification, but all real work will be delegated to a centralized
>	persistence service.  This persistence service handles caching,
>	locking, versioning, clustering and so on.  When persistence service
>	actually needs to manipulate data it delegates to a store manager
>	service.  The target initial store managers include SQL 92, SQL 99,
>	Oracle (which is not really SQL), file based (XML maybe), and we
>	plans to add LDAP, clustered database layer and some legacy systems.
>	The following ASCI picture sums this up (if it comes through):
>	                 ---------------
>	CMP ----------> |             | ------> SQL
>	JDP ----------> | persistence | ------> Oracle
>	Hibernate ----> | manager     | ------> LDAP
>	                 |             | ------> CICS (whatever)
>	                 ---------------
>	Now the persistence manager has a huge job, so it is broken down
>	plugins for caching, locking and so on, which effectively  makes the
>	persistence manager just a coordinator of the plugins.
>	Anyway, this is getting a little too technical for right now,
>	considering the initial code doesn't even have Entity beans.  From
>	I have seen, we have a similar vision, and I think we should talk
>	merging our efforts into a common persistence engine (maybe we can
>	get Gavin and the Hibernate team to sync up with us).  I think it
>	be really positive for Java to at least have all of us at least
>	so our systems can play well together, but if we joined forces....
>	-dain
>	On Thursday, August 7, 2003, at 07:02 AM, Mahler Thomas wrote:
>	> Hello all,
>	>
>	> I'm contacting you on behalf of the Apache OJB development team
>	> (
>	> OJB is part of the Apache DB subproject and aims at providing
>	> class
>	> standards based object relational mapping technology. We are
>	> finalizing our 1.0 release.
>	>
>	> Our team is excited to have a complete J2EE implementation at
>	> and we
>	> are willing to contribute to your project.
>	>
>	> OJB is heavily used in Tomcat, JBOSS and other application server
>	> environments and supports JTA and JCA.
>	> OJB provides special support for implementing BMP solutions
>	> It provides ODMG and JDO compliant APIs.
>	>
>	> That's why we feel that OJB is a natural choice if you are
>	> about a
>	> persistence engine to implement CMP (and maybe JDO). We are
>willing to
>	> integrate all necessary changes into our codebase.
>	> Who is working on persistence concepts? Whom could we contact to
>	> involved into the respective discussions?
>	> If you have any questions don't hesitate to contact me or the ojb
>	> developer
>	> mailing list.
>	>
>	> cheers and all the best for this new project,
>	> Thomas Mahler
>	>
>	> OJB developer
>	>
>	To unsubscribe, e-mail:
>	For additional commands, e-mail:
>To unsubscribe, e-mail:
>For additional commands, e-mail:

View raw message