Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
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)?
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?
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.
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
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".
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.
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
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
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Rama Raghavan<br />SCJP2<br />SCWCD
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)
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. |