File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes JDBC and the fly likes JDO and Web Applications Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Databases » JDBC
Bookmark "JDO and Web Applications" Watch "JDO and Web Applications" New topic
Author

JDO and Web Applications

Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
First off, I think transparent persistence is great! I am all for using a plain Java object model. However in JDO, to my knowledge, persistent objects can only be read or written outside of an active JDO transaction by being made transient, as they get their values from the JDO StateManager. Furthermore, transient instances cannot be reassociated (automatically) with a PM at a later point in time. This is not a problem in a client/server application when a single PM can be kept open, however it would seem to pose a problem in web applications. I get the impression that there are a few basic architectures for a web application using JDO:
1) Use a single PM to span multiple user requests and pass the JDO persistent objects between various application layers. The PM itself could be stored in an HttpSession or Stateful Session bean.
2) Create a new PM upon each request and make objects transient to pass information between the various application layers.
3) Create a new PM upon each request and use DTOs to pass information between the various application layers.
Option one seems to be the easiest choice from the development sense but I get the feeling that this could limit an application's scalability to have a bunch of PMs always open, not to mention having the possibility of long-running JDO transactions open across requests (yuck).
Option two seems to be okay only if your JDO implementation supports application identity so that you can get a JDO managed instance from the PM for your returned transient instance. It would be nice if the JDO specification would explicitly support this reassociation.
Option three is back to making DTOs, the very thing I despise about EJBs... I thought the reason we use JDO is for the rich object model. Furthermore, I get the feeling (from Craig and David's book) that this might even be considered the recommended solution.
Is this an adequate assessment? Am I missing something?
Craig Russell
Author
Greenhorn

Joined: Jun 16, 2003
Posts: 28
Your first approach can work if most of your access is nontransactional and there is a great deal of commonality among requests. The thing to worry about is cache management and concurrency, so this is best done with a small, frequently accessed set of objects.
If you're talking about layers being client and servlet (aka tiers), then the second and third approaches indeed work fine. If you're talking about layers within an application, then you can pass "live" JDO instances among the layers. Just make sure to keep the PM open.
Note that you can indeed read JDO instances outside of a transaction, similar to the way you use jdbc with autocommit on. The difference is that with JDO you can protect the updates with an optimistic transaction to guarantee transaction properties.

The JDO 2.0 spec (which hasn't yet started) will likely include a solution to passing instances from tier to tier while maintaining object identity and allowing disconnected updates. For a preview of what kind of functionality to expect, take a look at JSR 114, which offers disconnected operations on a JDBC RowSet.
Originally posted by Chris Mathews:
First off, I think transparent persistence is great! I am all for using a plain Java object model. However in JDO, to my knowledge, persistent objects can only be read or written outside of an active JDO transaction by being made transient, as they get their values from the JDO StateManager. Furthermore, transient instances cannot be reassociated (automatically) with a PM at a later point in time. This is not a problem in a client/server application when a single PM can be kept open, however it would seem to pose a problem in web applications. I get the impression that there are a few basic architectures for a web application using JDO:
1) Use a single PM to span multiple user requests and pass the JDO persistent objects between various application layers. The PM itself could be stored in an HttpSession or Stateful Session bean.
2) Create a new PM upon each request and make objects transient to pass information between the various application layers.
3) Create a new PM upon each request and use DTOs to pass information between the various application layers.
Option one seems to be the easiest choice from the development sense but I get the feeling that this could limit an application's scalability to have a bunch of PMs always open, not to mention having the possibility of long-running JDO transactions open across requests (yuck).
Option two seems to be okay only if your JDO implementation supports application identity so that you can get a JDO managed instance from the PM for your returned transient instance. It would be nice if the JDO specification would explicitly support this reassociation.
Option three is back to making DTOs, the very thing I despise about EJBs... I thought the reason we use JDO is for the rich object model. Furthermore, I get the feeling (from Craig and David's book) that this might even be considered the recommended solution.
Is this an adequate assessment? Am I missing something?
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
Originally posted by Craig Russell:
If you're talking about layers being client and servlet (aka tiers), then the second and third approaches indeed work fine. If you're talking about layers within an application, then you can pass "live" JDO instances among the layers. Just make sure to keep the PM open.

Yes, I was referring to tiers not layers. Sorry, for the confusion.
Originally posted by Craig Russell:
Note that you can indeed read JDO instances outside of a transaction, similar to the way you use jdbc with autocommit on. The difference is that with JDO you can protect the updates with an optimistic transaction to guarantee transaction properties.

Optimistic transactions are an optional feature correct? In a web application doesn't the use of optimistic transactions imply that the PM is going to be kept open between requests?
Originally posted by Craig Russell:
The JDO 2.0 spec (which hasn't yet started) will likely include a solution to passing instances from tier to tier while maintaining object identity and allowing disconnected updates. For a preview of what kind of functionality to expect, take a look at JSR 114, which offers disconnected operations on a JDBC RowSet.

Regarding JDO 2.0, has any timeline been identified?
Craig, thanks for your response. It basically confirms what I thought but it is much better hearing it from the source.
[ June 20, 2003: Message edited by: Chris Mathews ]
Craig Russell
Author
Greenhorn

Joined: Jun 16, 2003
Posts: 28
The timeline for all JSRs is a guesstimate but JDO 2.0 looks like around early 2005 for completion, about the same time as J2EE 1.5.

Originally posted by Chris Mathews:

Regarding JDO 2.0, has any timeline been identified?
Craig, thanks for your response. It basically confirms what I thought but it is much better hearing it from the source.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: JDO and Web Applications