Your jdbc/database connection is throwing this exception not your appserver;
I hope so.
william
-----Original Message-----
From: B.V.Murali Krishna [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 21, 2000 2:47 PM
To: [EMAIL PROTECTED]
Subject: Re: Serialized Access - few more questions?
hi James,
We are using Pramati_j2ee server it is giving like, if i sets the
isolation
level as TRANSACTION_READ_COMMITTED
It is throwing exception as it supports only TRANSACTION_READ_UNCOMMITTED.
If u have any piece of code please send that..
Thanks,
At 08:49 AM 7/21/00 -0400, you wrote:
>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".
>
>
>
MURALI KRISHNA BALUSA
VELOCIENT TECHNOLOGIES
NEW DELHI.
===========================================================================
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".
