Hi Folks,
I (and others here) are in the throes of trying to get a handle on some
transaction management issues that we probably should have dealt with much
sooner in our development cycle.
... any-who ...
Our scenario here is not unique ... but may not be common ...
a. We need to be able to do *direct* access to the DBMS viz-a-vis JDBC ...
and we are using CMP for entities.
b. We are building a sub-set of the whole application ... and there has been
little communication between parties thus far as to the ultimate deployment
configuration ... so it is not clear to me as to what kinds of issues we
might bump up against.
If you subscribe to the party line on this stuff ... application
deployment/configuration is billed as being something that can be done in a
black box so long as the component developer has specified her requirements
via a descriptor.
Yeah right.
If you look at container specific documentation, and start to look at
advanced clustering configurations, "domains", JDBC driver release notes etc
... things appear to not always be so cut and dry.
Thus far, I think we are making good progress in understanding the JTS/JTA
contracts/boundaries.
I think we also have a decent handle on descriptors as it relates to
transaction description/behavior requirements on behalf of the component.
Some of the things we are still scratching our heads a little about ...
a. We started off defining our own exceptions/exception hierarchy and
handlers as these exceptions bubble up the tiers ... including "transforms"
as they pass through ... for encapsulation reasons. When dealing with
container managed transactions, there are some specified behaviors with
regard to transaction management where exceptions occur. Generally, the
message seems to be that the container will assume that
"unhandled/unchecked" exceptions are to be bubbled up the stack, but first
the container will perform a rollback if the throwing method is operating in
the context of a transaction (or at least marks the transaction as
setRollbackOnly() so that the outcome is fixed). Further, I have seen posts
that advocate and even examples from Sun, that show throwing EJBExceptions
as a method of reporting "expected" exceptional conditions as a way of doing
"rollback and report" for business transaction management.
This goes against every grain I have ... as EJBException is ...
*) ... "non-descript" for the purposes of writing robust, obvious and
encapsulated code and components.
*) It is a "RuntimeException" ... or an unchecked exception, which generally
in Java is a subclass of exception to be used only in the rarest of
circumstances ... where things have gone awry to such a point as to be
"unexpected" ... and as such ... your API does not declare the conditions
through a "throws" of an excetion suitable for reporting the problem.
*) Per the Javadoc for EJBException, EJBException is to be thrown to report
"unexpected" conditions such as "the instance failed to open a database
connection". Typical business exceptions that require a rollback of a
transaction and a "report" to the user at to why their data was not
committed is NOT unexpected.
Having said all of that ... my thoughts on this are that the exception
handling code that is dealing with our "business" exceptions must also be
responsbile for call "setRollbackOnly()" where appropriate which should
force the container to rollback the transaction at the time that the "end of
transaction" demarcation is hit ... RATHER that rely on what I think is a
kludgy side-effect of throwing an "unhandled" exception.
Comments ?
b. As I indicated ... we are mixing "direct (JDBC)" and "CMP" database
access within a single transaction. The JDBC driver is resolved through a
DataSource and is JTS compliant (suppossedly).
One of the other questions that comes up is this:
Assuming that the JDBC access happens from a Session bean running within the
same container (JVM process) as the CMP entities ... and that the container
is resolving connections to the DBMS from the same pool of connections used
both by the JDBC code ... and the CMP infrastructure ... does anyone know if
it is specified or expected that ALL of the transactional stuff will occur
on the _same_ connection to the DBMS.
This is potentially important for issues of transaction isolation from the
perspective of data at the DBMS level.
Said a different way, given a context, a transaction and a "datasource" ...
will the "first" connection to the DBMS associated to a given context and a
transaction _always_ be used for all activity to a given datasource with a
transaction.
TIA,
Tony
---
Tony Pelton
Developer
tpelton at imany dot com
http://www.i-many.com
"Hail to the King, Baby"
===========================================================================
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".
