geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Test <>
Subject Re: [persistence] Some thoughts regarding CMP and JDO
Date Fri, 08 Aug 2003 17:06:05 GMT
Matthew Baird wrote:
> If I'm reading this correctly:
> 1. Version 1.0 is going to try and support several back ends other than just RDBMS's
> 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 value.
> 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 subprojects."?
> 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?

I think this is a good idea. I'm working with OJB in an Project and it 
is stable and configurable. I think we shouldn't waste ressources to 
make work again which is already done inside an Apache Project.

The ojb team around Thomas has offered  any changes of the codebase, so 
I think it would be possible to integrate the features we need.

Patrick Gwiasda

> cheers,
> Matthew
> 	-----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 implementation
> 	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 have
> 	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 into
> 	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 what
> 	I have seen, we have a similar vision, and I think we should talk about
> 	merging our efforts into a common persistence engine (maybe we can even
> 	get Gavin and the Hibernate team to sync up with us).  I think it would
> 	be really positive for Java to at least have all of us at least talking
> 	so our systems can play well together, but if we joined forces....  :D
> 	-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 first
> 	> class
> 	> standards based object relational mapping technology. We are currently
> 	> finalizing our 1.0 release.
> 	>
> 	> Our team is excited to have a complete J2EE implementation at Apache
> 	> 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 easily.
> 	> It provides ODMG and JDO compliant APIs.
> 	>
> 	> That's why we feel that OJB is a natural choice if you are thinking
> 	> 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 get
> 	> 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:

View raw message