Ken,
You are never dealing directly with the 'real' jdbc connection. Instead the
container dispenses a connection wrapper which intercepts your close and
many other jdbc statements. This technique is well known and used by our
CORBA transaction service long before EJB came along. This technique also
allows for connection pooling while at the same time reducing the number of
tx's requiring 2pc. When you ask for a connection for a datasource the
connection is assigned to the current transaction. Any subsequent calls for
a connection i.e. open, from the same datasource will return you the initial
one created and assiged to the current tx. If two of your beans reference
the 'same' datasource then there will be only one active connection so the
container does not need to perform the 2 phase commit protocol. The commit
command will be executed once. Of course if the datasources references are
different then you will require 2PC, or relax the acid properties and
provide some compensation actions (not really recommended), or just pray.
William Louth
Inprise
www.inprise.com/appserver
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Kenneth D. Litwak
Sent: Monday, September 11, 2000 4:26 PM
To: [EMAIL PROTECTED]
Subject: EJBs and the two phase commit
This is not precisely a contnuation of the current thread, but the header
does
address my questions.
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(). What ifI'm accessing
multiple data sources? 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?
Second, Javasoft recommends opening and closing db connections within
3very
database-related method. That raises a problem for me, unless (I'mmissing
something. Here's a scenario to show why:
Mtthod a opens a connection, updates the database and closes the
coonnection.
Method B opens a connection, does some work and closes the connection.
NOq, two questions:
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?
That is, nohting is tracking, so far as I know, what was changed by method A
anymore. WIll this situation simply fail to call commit() on any local
resource
maanger, thus causing the cahched changes (cached in the database) to be
ignroed? Or what? 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.
Ken Litwak
===========================================================================
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".
===========================================================================
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".
