hi all,
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.
Thanks in Advance,
At 10:36 AM 7/12/00 -0400, you wrote:
>I am longing for some of the more meaningful discourses that this group was
>famous for before EJB became the technology de jour. ;-)
>
>I know that EJB development simplifies many of the aspects of producing
>distributed software. The most obvious plus is the transaction support.
>However, one of the more insidious problems with architecting distributed
>solutions is concurrency control. I am interested in finding out how some of
>the more popular app servers assist the developer in managing concurrency,
>particularly in respect to entity beans.
>
>I can start by mentioning the app server I am most familiar with, Inprise
>Application Server. This server does not serialize access to entity beans.
>If two clients want to work on the same entity bean, IAS will create two
>separate instances of the bean. Both clients can modify the bean
>simultaneously. All concurrency is pushed to the database. I suppose this
>can be best termed as an example of optimistic concurrency. This design
>promises high availability within the container, but causes the developer to
>carefully manage concurrency issues with the database. The developer has to
>ensure the db has not been modified since the last read.
>
>The opposite side of the coin is pessimistic concurrency. This is when the
>app server serializes access to the actual beans in the system. As long as a
>particular instance of an entity bean is involved in a transaction, no other
>client can start a new transaction on that bean. Obviously, there are
>tradeoffs in both systems, but pessimistic concurrency greatly simplifies
>the developer's responsibility while, most likely, sacrificing performance.
>
>How about these other web servers? What approaches do they use? Is weblogic
>and websphere pessimistic by nature? What are some solid approaches for
>reducing concurrency issues in an optimistic container especially when
>dealing with course objects?
>
>It's highly possible that we could develop a concurrency test for all EJB
>servers. If we have a simple table with an int column, we could write an EJB
>that increments this value by 1. After hitting the entity bean with multiple
>clients for an hour, we can verify concurrency by checking for any duplicate
>values. We could also compare the transactions per second easily.
>
>Fun stuff?
>jim
>
>===========================================================================
>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".
