"Beauchemin, Bob" wrote:
> Now the questions...
>
> Does any vendor currently support the XA+ standard for communicating among
> multiple XA TMs? Could I start a transaction on product A and enlist RMs
> through another TM from another instance of product A TM or instance of
> product B TM? And if both TMs are product A, do you use XA+ (I realize its
> not covered by the spec) or a propriatary mechanism?
I believe the J2EE way to have AppServers from multiple vendors participate in
a single global distributed transaction would be via the JTS specification,
which means using the OMG's OTS specification under the covers. That is
certainly what we would interoperate against, and what the majority of other
vendors would be supporting for interoperable transactions.
> Does anyone support 2PC with transactional file system or an extensibility
> mechanism to write your own esoteric, non-DBMS or JMS RM? I realize J2EE
> connector spec is here, but that appeared to be more "legacy system" related
> rather than something as mundane as a transactional file system.
Again, using the JTS/OTS APIs, implementing your own resource is fairly
straightforward. Well, at least the part of hooking into the TM is
staightforward; actually doing the right thing in terms of (a) supporting
2PC, and (b) allowing for recovery is clearly non-trivial in many cases.
We provide an example of how to do this in our product in:
<ias-installation>/examples/ejb/custom_cmp
Note that this example also shows how to plug a custom CMP engine into our
product (which is how various O/R tools such as CocoBase, Avantis, Poet and
TOPLink all plug into our product, incidentally), but it does have the
basics in place to show how to implement a transactional resource. (Note
that the trivial example provide is not 2PC enabled, as this would complicate
the example unnecessarily.)
> How about future support for running a separate EJB 2.0-compliant, plug-in,
> persistence manager?
As it turns out, plugging in an EJB 2.0-compliant persistence manager is
relatively straight-forward, and I know a number of vendors are working on
this for our product (and of course also for other products). Typically
this would be done using the "BMP extends CMP" pattern, although other
styles of integration (such as using a CMP SPI, as we provide for EJB 1.1)
are also possible, using a vendor-specific API. The road-map for future
EJB specifications discusses the fact that a standard PM SPI will be
provided at some point.
> Thanks again,
> Bob Beauchemin
> [EMAIL PROTECTED]
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
