Hello Ken,
> 1. Does the EJB spec specify two=phase commit for EJBs, via, I presuem,
JTA?
> That is, if I am runnign a transaction, with multiple emthod calls, each
of
> which should cause an update to the database, and hence, as I understand
it, an
> ejbSStore () (is this always called for an entity bean method?), at some
point
> the local resource managers have to do a commit().
No, spec 1.1 and 2.0 does not specify mandatory 2PC for an EJB container.
JTA is only a simple interface to a transaction service, not the standard
for its architecture. This would be JTS, and JTS is only recommended but not
mandatory. JTS was only mandatory in EJB 1.0 and Sun got a hell lot of
problems with the container vendors because they thought the sepc is
regulating to much of their container architecture so they took it out.
> Does he commit() in each resource manager happen and
> then the transaction commit? What if one resorue maanager fails to do a
commit?
> Does the container take notice of this, and if so, how can it rollback
changes
> already committed in another resoruce amanger?
In JTS you have a concept standardized by the XOpen Group for distributed
transactions. A transaction manager communicates with resource managers,
e.g. a database, in a 2PC way. The protocol between manager and resource is
the so called XA protocol. The TM sends a prepare message to all resources
before a commit. If a prepare fails at a resource the whole transaction can
be rolled back. Prepare means that the resource is able to commit a
transaction, e.g. writing all buffers and logs to disk, in all
circumstances. Only when all resources vote for VOTE_COMMIT in their prepare
phase the TM will send a commit to each resource.
> Assuming these two methods were called under the same transaction:
> If method B fails (could be in the same or a different bean), how does
the
> container know that it needs to rollback what happened in method A, since
> there's no longer a "connection" between the bean instance and the
database?
The TM does not need physical connection to keep in track with a
transaction. It's important to have a transaction context promoted with each
method call on a Enterprise Bean. A transaction context for example could
exists of a transaction id and some other information. If B fails within a
transaction context with an id let's say 4711 then the TM knows which
methods on which bean were invoked with the same transaction context. Of
course the TM has to track the method calls with the transaction context,
but it does not need a phsical database connection.
> That is, nohting is tracking, so far as I know, what was changed by method
A
> anymore.
As I wrote, the TM knows through the transaction context which resources
were involved.
> How will the dbms know that work done unde a different, now
> gone, database connection needs to be rolled back, since commits are
generally
> done on a local resourcce manager on work done in a given connection.
That
> connection, however, is now hitory.
You have to separate between connections and transaction. It's right you can
vote for begin() or commit() on a java.sql.Connection, but that's only an
interface and must not represent a real physical database connection. A DMBS
has its list of working transaction through the transaction contexts and
they're not hard wired to a physical, e.g. TCP/IP, connection. A real
physical database connection can handle a lot differenent transactions. If a
TM rolls back a transaction it would send the proper transaction id to the
resource manager and the DMBS can start to roll back its internal
transactions with that id.
regards,
--
[EMAIL PROTECTED]
MATHEMA Software GmbH
N�gelsbachstra�e 25 b
91052 E r l a n g e n
D e u t s c h l a n d
Tel +49(0)9131/8903-0
Fax +49(0)9131/8903-55
http://www.mathema.de
===========================================================================
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".
