Good point about the timing of the actual database work, that's up to the
container in the CMP case so it usually happens at the very end. This can
be funky just within the case of calling remove on a bean (probably goes to
the database right away) vs making updates which wouldn't get written to the
database until ejbStore is called at the end of the transaction.
Another point around the connection issue is that if you've got a real XA
compliant driver and database you don't need to worry about whether you get
the same connection back again (some fuzziness about the closeness of the
transaction branches). You will see the changes (I presume that is the
behavior you want) from both logical connections however they map onto
physical connections. I think that most DataSources do what you would
expect, which is map connections onto transactions and keep returning the
same connection for a given transaction.
Cheers
-----Original Message-----
From: Johan Eltes [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 10, 2001 8:47 AM
To: [EMAIL PROTECTED]
Subject: Re: Transactions
For a)...
I agree. You shouldn't use runtime exceptions related to business rules.
Unfortunately, transactional behaviour has not been mapped to application
exceptions in specs above 1.0. Contrary, the spec says that a component
throwing an application exception must recover its state, before doing so.
Well, the concept of recovering state in a transactional environment is to
rollback, isn't it? What if component A is fine but component B (called
after A) is not fine and throws an application exception? Who is responsible
for "post-recover" of component A? Persistence has been mapped to Entity
beans. We are hidden from threading, load balancing and many other things.
It would be great if the spec writers would map rollback to exceptions (of
any kind) and map commit to successful execution (no exception). Then we
would get transparent transaction handling, nicely and naturally mapped to a
java language construct. Applications that do need to manage transactions
would then use Bean-managed transactions or client-managed transactions. We
could get rid of setRollbackOnly. And the spec writers would not have to
write complex sections of text defining the relationship between
transactions and different types of exceptions. They would also not have to
define how bean-managed transactions relate to setRollbackOnly. In the
meanwhile, I think the best work-a-round is to always have a
(none-composable) top-component that takes the transactional decision, on
behalf of the container. This component can use Bean-managed transactions or
call setRollbackOnly.
For b)
I think all containers that are an option for your project will return the
proper Connection for you, also in combination with CMP. However, there are
some other risks when combining the two, mainly related to the
direct-to-database access style of JDBC calls, versus
delayed-until-end-of-transaction access style of CMP actions.
/Johan
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Tony Pelton
Sent: Tuesday, July 10, 2001 1:17 PM
To: [EMAIL PROTECTED]
Subject: Transactions
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".
===========================================================================
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".
