This week's book giveaway is in the OCPJP forum.
We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line!
See this thread for details.
The moose likes Object Relational Mapping and the fly likes Combining JDO with other persistence mechanisms Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Databases » Object Relational Mapping
Bookmark "Combining JDO with other persistence mechanisms" Watch "Combining JDO with other persistence mechanisms" New topic
Author

Combining JDO with other persistence mechanisms

John M Brown
Ranch Hand

Joined: Nov 29, 2001
Posts: 62
One particular challenge that we have had on our project is combining JDO with other objects that are not managed by JDO. For example, we have an object whose type is the class Guest that is related to other objects persisted in the database using JDO. The guest object is managed from another system and only a reference is stored to guest for the other objects. In order to navigate to guest, we need to use another mechanism besides JDO (ie, DAO, EJB, or Web Services)

It would be great to be able to access these objects similar to navigating in JDO (maybe if the object could be accessed via a JCA connector or other mechanism).

Have you run into any of these scenarios (that particulary come up in an enterprise environment), and are there tips and tricks to make it easier?

Thanks,


<a href="mailto:JBROWN2002@cfl.rr.com" rel="nofollow">JBROWN2002@cfl.rr.com</a>
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995
I thought that JDO is a specification that will take away from the dev exactly this kind of problems. I may be wrong - as I am more on the ORM side, but afair from reading the spec, JDO should leverage the access (through PersistenceManager) to persisted entities whatever is the backend persistence engine.
Isn't JDO going in the same direction EJB spec was going too?

./pope


blog - InfoQ.com
John M Brown
Ranch Hand

Joined: Nov 29, 2001
Posts: 62
Hi Ali,
That is true for any persistence mechanisms you are accessing through a datasource. But it's a little more complicated when you are trying to access an object that you cannot go directly to some other system's datasource to get. other systems may not let you access the datasource diretly (for good reason). In this case, you need to call some API to get it (ie EJB, Web Services, or some other mechanism)

I do know that JCA connectors are treated similarly to datasources, so if JDO integrates with JCA, it might be easier to abstract objects that are accessed through different mechanisms besides through a datasource.

I guess I'm more talking about a type of JDO adapter for remoting.

I'll check out some more documentation on Kodo today to see if I can learn more on the configuration side.
Greg Campbell
Greenhorn

Joined: Nov 11, 2004
Posts: 2
Unfortunately, this question doesn't have a great generic answer. Let me first make a couple of initial points:

* Most JDO implementations are deployed into your container as a JCA resource
* Most JDO implementations are O/R mapping tools that implement the JDO specification. That said, the JDO specification doesn't force you to sit on top of a relational data store. JDO implementations can sit on top of other EISs, also.
* For various reasons (in particular, transactional integrity) a JDO implementation will not try to manage more than one DB/EIS within the same PersistenceManagerFactory. To do that properly (that is, to maintain transactional integrity across multiple DBs/EISs), you need XA, and thus it makes sense to run inside a container that provides XA.

So, the bottom line is that a JDO implementation might handle an arbitrary EIS, but handling two separate DBs/EISs while providing seamless navigation is a hard problem (the federated DB/EIS problem). If you deploy your JDO implementation(s) as a JCA resource(s), then they can participate in XA transactions, but for the navigation part, you'll need to do something on your own. But both your DB and your EIS could theoretically both be handled by JDO implementations deployed as JCA resources.

Thanks,
Greg


Greg<br />www.solarmetric.com<br />The makers of Kodo JDO
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995
Very nice point Greg.
Hoewever a little mistake got in (imo):

Most JDO implementations are O/R mapping tools that implement the JDO specification. That said, the JDO specification doesn't force you to sit on top of a relational data store. JDO implementations can sit on top of other EISs, also.


When we talk about O/R we talk implicitely about relation data store .

./pope
Greg Campbell
Greenhorn

Joined: Nov 11, 2004
Posts: 2
That's what I meant by O/R. Most JDO implementations work only with relational databases.
Thanks,
Greg

Originally posted by Ali Pope:
Very nice point Greg.
Hoewever a little mistake got in (imo):


When we talk about O/R we talk implicitely about relation data store .

./pope
Thomas Whitmore
Ranch Hand

Joined: Aug 05, 2004
Posts: 33
Hi John,

This is an easy question with a good generic answer. Basically, you've already described the solution.

One particular challenge that we have had on our project is combining JDO with other objects that are not managed by JDO. For example, we have an object whose type is the class Guest that is related to other objects persisted in the database using JDO. The guest object is managed from another system and only a reference is stored to guest for the other objects. In order to navigate to guest, we need to use another mechanism besides JDO (ie, DAO, EJB, or Web Services)

As you say, your immediately accessible system only stores references to the Guest object; with programmatic execution needed to access that other system across the boundary.

Essentially, you duplicate this structure with JDO. JDO doesn't change or move system boundaries in general, just gives you integration of object model to database.

Your JDO objects then have a GuestRef or GuestFK field which is persistent like any other data, and a 'boundary crossing' business method which will programmatically perform that remote execution/ access; perhaps by calling a local facade for services on that external system.

This achieves correct separation between 'locally owned', directly storable data over which your app has control - the GuestRef - and the programmatic connection and interaction with the external system - which is outside your app's boundaries.

You'll find that this structural separation is, both theoretically and practically, correct. eg Local updates, not changing the Guest data, are reliable and won't have to handle the remote-related exceptions; updates which involve Guest OTOH may be unavailable if the remote system goes away.


If you want more OO support for editing and updating the remote Guest, this can be done too. The technique here is to implement a GuestHandle, to model and manage then external data.

Handles hold field values and state under editing, and are the correct solution to unify remote or decoupled data into an object model. Populating the handle and updating back to the database, are additional actions performed at the begin/ commit points of those usecases.


This should give you a good solid approach, which fits the real-world possibilities without trying to paper over the cracks. Handles in particular are a perfect design solution for external or decoupled data.

Hope this helps,


Thomas Whitmore
www.powermapjdo.com
 
 
subject: Combining JDO with other persistence mechanisms