This is also the approach we have done...messaging. First we used RMI
callbacks a couple years ago. Now we will use JMS, but there is nothing to
prevent you from using any messaging product, even JavaSpaces would be
ideal.
The trick is to be sure to use good design patternson the client to manage
these updates. If all you are doing is indicating that the "object has
changed...refresh" to the user then it is not so bad. However, if the user
is not actively editing an object (or the object is not displayed yet), why
not refresh it automatically? If course, this depends on your applications
needs.
What app server are you using that does not support transaction isolation?
Usually, they just pass this setting on to the database connection object.
jim
----- Original Message -----
From: "Rickard �berg" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, July 21, 2000 6:10 AM
Subject: Re: Serialized Access - few more questions?
On Fri, 21 Jul 2000 14:25:06 +0500, B.V.Murali Krishna
<[EMAIL PROTECTED]> wrote:
>The Application Server we are using does not support Transaction Isolation
>Level. But its the application requirement due to high transaction amount
>we need to maintain the sanctity of the database.
>
>Consider Client A that accesses a Enity bean CBean and read the data, after
>that
>Client B accesses the CBean and read the data. Then Client A modifies one
>record
>and then Updated the record.
> Now Client B having the old data, to get the new data how to handle that
>situation
>(we need here as Client B should get the message like "Refresh the Screen,
>Somebody has modified
>the data". )
>
> If the Application Server doesnt support the Transaction Isolation Level,
>What is the best
>way to handle the Situation.
It would seem as though the best way to handle this is to register
clients as JMS clients and let JMS propagate update messages to client.
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
===========================================================================
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".
