Hi all,
Thank you very much for your replies.
Rickard wrote:
>> -- Long transactions are blocking other accesses; in particular "read"
>> accesses, with no reason. We do not want to block an E-Beans for
>> read when another client writes it and has not committed yet.
>> (non-blocking writes are typically provided by database vendors
>> like Oracle).
>
>Just a hunch: would it be possible to mark the bean as "TX_REQUIRES" but
>mark those methods not needing tx:s ("read":s) as "TX_NOT_SUPPORTED"?
Since EJB 1.0 dose not allow to do such "dirty read",
it's not possible in EJB 1.0.
>Cache management when not in a transaction (i.e. TX_NOT_SUPPORTED is
>used) is interesting. When should ejbLoad/ejbStore be called? Whenever?
>After each call ("just in case")?
Yes, "just in case".
Ian McCallion wrote:
>Transactions should never be designed to be long. At least, not "long" in the
>sense that they spans human interactions - it is neither what the human wants
>nor what the computer wants. For the human, think what happens if the
>transaction aborts - everything, except the human, will back out. (Actually,
>come to think of it, she may backout too, though in a different way). For the
>system, think what happens if the human goes to lunch - database locks will be
>hanging out indefinitely.
But in real application, there are many cases that "long" transaction
will be needed.
>
>Design your transactions to be short and use a stateful session bean to
>maintain continuity over a series of human interactions. Use a reliable EJB
>server to ensure that the session beans do not get lost and cause your users to
>back out.
Sachin Aggarwal wrote:
>But what if the user is going through a series of steps where each step
>requires user interaction and the steps should not be committed till all the
>steps are done. On one hand there's the issue of user going for lunch and
>hanging locks and on the other hand there's the issue of the system having
>commited to the the database only half the steps and user decides to log
>out.
>
>A typical example would be a user looking up a custom order , getting it's
>custom spec , changing the custom product spec , changing the shipping
>address on the order and then logging out.
Yes, complex business objects often need to be treated in "long" transaction.
>
>I'm being faced with this issue ? would you put these steps as different
>operations on a session bean ? When would you start the transaction and when
>would you commit it ?
Jim Frentress wrote:
>if you truly need to provide concurrent access to an order (which it isn't
>clear that you actually do) then you do have a number of options. one option
>is a logical lock whereby you "check-out" the order for editing. another
>option (probably better for your example) is to be more optimistic. read the
>order (which has a LastTouched timestamp) without concern for locking. when
>the user issues a save operation, begin a transaction to make your changes.
>just before applying your changes, see if your timestamp matches the order
>timestamp. if it does, you can safely apply your changes. if the timestamps
>don't match, then you apply a business rule. you can of course handle
>logical locking at a finer level but this demonstrates the idea well enough.
I believe that "long" transaction does not mean to prevent other clients
from accessing the object completely. In other words, non-blocking operation
should be available during the transaction.
I consider we may need some primitives for controlling the concurrent access
independently from transactions.
-----
Best Regards
Yasuaki SUGINO
FUJITSU LIMITED
===========================================================================
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".
