• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

JDO and transactions

 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
How does JDO jive with transactions? Is the database connection used by a JDO implementation registered with a Transaction Manager of a J2EE container if the persistence operation is "invoked" in the context of a transaction? How about when using filesystem instead of a database to back up the JDO layer?
 
Author
Posts: 66
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Craig implemented JDO within the Sun One CMP environment, so he can provide you with more complete details, but yes, JDO can work with either container managed transactions or bean managed transactions. The JDO implementation must provide some integration in order to interoperate with the application server's transaction manager. In the case of using JDO against a file, the JDO implementation would need to implement its own transaction facility. Craig led the development of the JDO reference implementation too, so he can provide more details on this.
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks again, David.
I kinda figured that the implementation has to provide the transaction support for file-based persistence... Does the JDO standard/API specify any interface for the client code to figure out whether transactions are supported by the JDO implementation (thinking of the case where the developer doesn't know which JDO implementation and which underlying datastore will be used in a deployment)?
 
Author
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
All JDO implementations must support datastore transactions; only optimistic transactions are optional, although most implementations support them as well.
There is an API on PersistenceManagerFactory that returns a String[] of all the optional features supported by an implementation.

Originally posted by Lasse Koskela:
Thanks again, David.
I kinda figured that the implementation has to provide the transaction support for file-based persistence... Does the JDO standard/API specify any interface for the client code to figure out whether transactions are supported by the JDO implementation (thinking of the case where the developer doesn't know which JDO implementation and which underlying datastore will be used in a deployment)?

 
Craig Russell
Author
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
JDO is designed to run inside a managed environment where transactions are either managed by the container or by the application. Typically, where the application server supports UserTransaction, the JDO Transaction is not used for transaction demarcation. Instead, transactions are declarative, applying to specified session bean methods, or programmatic, invoked by the body of the method.
When the application calls a JDO operation, the JDO implementation is responsible for determining the transaction context by using application server specific APIs. Unfortunately, the specification for J2EE servers doesn't yet provide a standard interface for this, but all servers provide APIs, and JDO vendors use them.
There is an extensive discussion of this topic in the book (of course).

Originally posted by Lasse Koskela:
How does JDO jive with transactions? Is the database connection used by a JDO implementation registered with a Transaction Manager of a J2EE container if the persistence operation is "invoked" in the context of a transaction? How about when using filesystem instead of a database to back up the JDO layer?

 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Craig Russell:
When the application calls a JDO operation, the JDO implementation is responsible for determining the transaction context by using application server specific APIs. Unfortunately, the specification for J2EE servers doesn't yet provide a standard interface for this, but all servers provide APIs, and JDO vendors use them.


<starting to get off-topic...>
Would you happen to know how do the JDO implementations figure out which proprietary API to call? The first and probably not the best way I thought of was to add a sequence of trial-and-error type of attempts to use something server specific and based on a successful attempt to call com.beasys.this.and.ThatService decide, "ok, we're deployed on a WebLogic Server 7.0, let's use the WLS-module from now on".
 
Craig Russell
Author
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There are a lot of techniques possible. I'll tell you how the JDO RI handles it.
We depend on the ability of a server to load a class at startup. This server-specific class might implement a special server life cycle interface, or simply be any old class. What this class does is to instantiate the server-specific implementation of the required JDO RI interfaces used to determine the transaction context of the calling thread, register for transaction completion, etc.

Originally posted by Lasse Koskela:

<starting to get off-topic...>
Would you happen to know how do the JDO implementations figure out which proprietary API to call? The first and probably not the best way I thought of was to add a sequence of trial-and-error type of attempts to use something server specific and based on a successful attempt to call com.beasys.this.and.ThatService decide, "ok, we're deployed on a WebLogic Server 7.0, let's use the WLS-module from now on".

 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Craig Russell:
We depend on the ability of a server to load a class at startup. This server-specific class might implement a special server life cycle interface, or simply be any old class.


A couple of questions about this part.
1) By whom is this server-specific class loaded?
2) How is the "at startup" part achieved?
Btw. You and David have been extremely active on this forum, which is nice
 
Craig Russell
Author
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
1. The server loads the class, usually by the sysadm asking for it in the server's startup script or xml.
2. Servers typically allow "user code" to be run via a startup class during server initialization. This is after standard services such as jdbc connection pools, jndi, jms, etc. are initialized, but before user-specific services like bean containers. Some servers (and I hope this can be standardized by J2EE) provide life cycle callbacks, e.g. server-startup, server-shutdown, container-load, container-unload, application-deploy, application-undeploy.
P.S. I was told that you would appreciate our logging in regularly, and I was told right!

Originally posted by Lasse Koskela:

A couple of questions about this part.
1) By whom is this server-specific class loaded?
2) How is the "at startup" part achieved?
Btw. You and David have been extremely active on this forum, which is nice

 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So, the JDO vendor has to provide a bunch of appserver specific classes AND instruct the application deployer to configure a startup class to be loaded/run upon server startup. As long as the J2EE spec doesn't dictate the startup class interfaces/configuration, the JDO vendor has a lot to do...
- startup class (x number of appserver vendors)
- class for getting the tx context (x number of appserver vendors)
- configuration instructions for the deployer (x number of appserver vendors)
 
Ranch Hand
Posts: 116
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
1. Does JDO support/provide for distributed transactions ? Does JDO operations on an object become part of an enclosing Usertransaction ?
2. I haven't read the API much, but say if I Abort a transaction, I am guessing the object will go to its original state automagically and I do not have to make additional calls for reinitializing the object from the DB..?
 
David Jordan
Author
Posts: 66
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'll let Craig answer the question about the distributed transactions and UserTransaction. JDO does not have explicit support for distributed transactions, but the way the spec is written, it allows for an implementation to support this.
As far as your other question, there are two boolean flags that are relevant: RetainValues, RestoreValues. RetainValues controls whether the objects should remain in the cache at transaction completion. RestoreValues controls whether you want the state of objects restored as of the beginning of the transaction or not on rollback. You can set these flags to true or false, giving you complete control over this behavior.
 
Craig Russell
Author
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It turns out that there is one main thing to do, which is to create the infrastructure, and as you point out, "x" minor things to do.
Most app servers provide for lookup of the TransactionManager which gives you the api for finding the transaction context of the calling thread. This same interface gives you the ability to register for transaction completion callbacks.
I'd say the hard part in all of this is the database interface (jdbc and Java Connector Architecture) and the interfaces discussed here are minor in comparison.
And there are just not that many application server environments nor differences among them.
Besides, this is a JDO vendor responsibility. The only thing users need to worry about is configuring their JDO according to the application server it's being used with. All of this is clearly spelled out in the JDO documentation...

Originally posted by Lasse Koskela:
So, the JDO vendor has to provide a bunch of appserver specific classes AND instruct the application deployer to configure a startup class to be loaded/run upon server startup. As long as the J2EE spec doesn't dictate the startup class interfaces/configuration, the JDO vendor has a lot to do...
- startup class (x number of appserver vendors)
- class for getting the tx context (x number of appserver vendors)
- configuration instructions for the deployer (x number of appserver vendors)

 
Craig Russell
Author
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
JDO does not provide a special API to control distributed transactions. This is handled transparently (no surprise) in environments that support distributed transactions.
Distributed transactions are a superset of coordinated transactions. Distributed transactions involve multiple "client" address spaces with multiple "server" resources. Coordinated transactions involve multiple "server" resources.
JDO defines coordinated transactions as those involving multiple PersistenceManagers. There is limited support outside the application server for coordinated transactions. Within the application server, both coordinated and distributed transactions are implemented by the server, and the JDO vendor simply needs to connect into these services.
Consider JDO as just another client using jdbc connections. When your application gets a jdbc connection and there is a UserTransaction active, the application server automatically performs the coordination function so that the commit uses the two-phase protocol to guarantee atomicity.
So to use JDO with coordinated or distributed transactions in the application server, use either container-managed transactions or bean-managed transactions via UserTransaction. Verify with your JDO vendor that they support UserTransaction (it's part of the JDO specification but it can't hurt to ask!). When you begin the UserTransaction and then get a PersistenceManager from the PersistenceManagerFactory, the PersistenceManager is automatically enlisted (including any jdbc connections) in the current transaction. When you commit, the changes you made to instances managed by JDO will be committed in coordination with any other changes made in the same UserTransaction, whether in the same or other server.
There is more discussion of these issues in the book (no surprise.)

Originally posted by Rama Raghavan:
1. Does JDO support/provide for distributed transactions ? Does JDO operations on an object become part of an enclosing Usertransaction ?

 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic