Chip Wilson wrote:
> 1) In the spec, a phrase is often used, but I can find no definition for it.
> What does the phrase "this method will be called in the proper transaction
> context" mean? Specifically, does this statement imply that the method will
> always be called within a transaction?
The long version is "this method will be called in the proper
transaction context with respect to the deployment descriptor of the
bean". I.e. if you have marked the bean as transactional then there
should be a transaction running, and vice versa.
> 2) The sequence diagrams for entity beans with BMP show the underlying
> persistent store, represented by "database" on the diagram, registering
> itself with the same transaction service controlled by the
> javax.jts.UserTransaction. How can this be? My persistent store may be a
> legacy system that knows nothing about EJB, how could it know to register
> itself with the server's transaction mechanism?
If you want the bean to be transactional, even though you're using BMP,
your underlying store must be able to hook itself into the transaction
manager. It can do this by following the instructions in the JTA spec
(in short: the JTA impl. must register an interface object in JNDI which
resources can use to receive transactional notifications).
> 3) Let's say that I update two entity beans with BMP within the same
> transaction. I commit the transaction, and the container calls ejbStore on
> the first bean. This succeeds, and the container calls ejbStore on the
> second bean. During this call, the underlying persistent store rejects the
> update. Now, it would seem that there is no way to rollback the
> transaction. If the container calls ejbLoad on the first bean, it will load
> the data it just stored.
See above, and this is not a problem. However, since there aren't too
many resource managers that do these hookups yet it will take some time
before this becomes a practical reality and not just something written
on a paper.
But then there's the issue of why you want transactions. In most
discussions people say "to transact or not to transact" (etc). But there
are really three levels of transactions: no transactions, full
transactions, and transactions which only handle deterministic
rollbacks.
So what does "deterministic rollbacks" mean?
Well, rollbacks which you describe above are non-deterministic in the
sense that the operation should work, and there's no way to know that
they will happen unless you run the code. Deterministic rollbacks are
those that stem from a deterministic error, such as a business method
throwing a checked exception. With the same state and the same method
input the same exception will be thrown each time.
This kind of transaction are useful for example in the classical bank
example(two accounts, withdraw from one, deposit in another, rollback if
too much withdrawn). Let's say we do it backwards just to make it
difficult: we deposit first some amount in one account, and then we try
to withdraw the same amount from the other account. But since this
amount is not available we get a checked application exception. Now we
rollback the transaction because of this and the EJB server will evict
the instances from memory, hence removing all evidence of the first
deposit. A consistent state is preserved.
What this means really is that if you want the safety of full
transactions, and have the hardware to handle the extra overhead, then
that is fine. But if you don't have transactional resources, or full
transactions would be too heavy performance wise, you can still mark the
beans as transctional and be able to rely on the deterministic rollback
handling of the EJB server to preserve consistent states during "normal
application running".
HTH :-)
/Rickard
--
Rickard �berg
Computer Science student@LiTH
@home: +46 13 177937
Email: [EMAIL PROTECTED]
Homepage: http://www-und.ida.liu.se/~ricob684
===========================================================================
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".
