How about one of the following:
1 entity bean as you describe, to handle the persistence. It is TX_REQUIRED
1 entity bean to encapsulate the external device, it is TX_NOT_SUPPORTED
1 session bean to wrap the two, it is TX_SUPPORTS.
First the session bean calls the TX_REQUIRED EB, a transaction starts and
commits.
Then it does the comminication with the external device by calling the
method on the second EB
If success, it calls the first EB again, in a new transaction.
Or:
The session bean is TX_REQUIRED.
Calling the TX_NOT_SUPPORTED EB will result in a suspend on the transaction
and a resume
when it comes back. Then both updates run in a single transaction that
doesn't get fauled up
if the communication with the external device fails.
Frank Sauer
The Technical Resource Connection
Tampa, FL
http://www.trcinc.com
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Sveta Mordkovich
> Sent: Thursday, February 10, 2000 7:03 AM
> To: [EMAIL PROTECTED]
> Subject: TX_NOT_SUPPORTED & stateless session bean concurrency
>
>
> Hi all,
>
> We have a server-side object which has to perform the
> following sequence
> in its update() method:
> - update the DB row it represents
> - perform some communication with an external device
> - update the DB row according to the success of the previous step
>
> The two DB updates should not be performed in one transaction.
>
> As far as I understand there are two design solutions:
> 1. implement this object as an Entity Bean using BMP in which
> the object's update() method will explicitly perform the
> DB updates.
> (and use TX_NOT_SUPPORTED for the update() method).
> 2. Use an entity bean to implicitly handle the object persistence
> and wrap it with a statefull session bean which will perform the
> logic described above.
>
> It seems to me that the second option is preferable, but then
> the question is how will the session been handle multiple
> concurrent invocation of update() method keeping in mind
> that the method does not make use of transaction to perform
> the 2 DB updates.
>
> Any comment will be highly appreciated,
>
> Sveta
>
> ==============================================================
> =============
> 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".
