Ken,
The topic has been thrashed around for quite a while
now. With the Borland AppServer, you can use the
"SELECT ... FOR UPDATE [nowait]" to perform pessimistic
locking at the database level (with CMP). This would result
in the behavior you describe below.
Of course, the above approach works - but in a large
scale application where high concurrency and transaction
throughput are primary factors, it could result in
non-scalability. (E.g. - the performance of read-only
transactions would be affected by database locking).
<vendor>
The section called "Concurrent access from multiple transactions"
in the EJB specification discusses two types of entity bean access.
We implement the model for multiplexed access. That is, multiple
clients can access the entity bean simultaneously, without locking
at the container level. Note that locking may occur at the database
but will not occur in the container.
</vendor>
WebLogic (pre 6.x) performed locking at the container
level - i.e. one instance serviced all requests. So, you
would get the behavior you request below- but - obviously
this is not a scalable solution and the basic approach
is flawed as it is broken in a clustered environment.
A better solution is to use verified updates, which
essentially performs an update along the lines of:
"UPDATE <table> SET(values_of_ modified_fields) WHERE
<all_cmp_field_values_are_values_read_in_at_start_of_transaction>"
The Borland AppServer uses the above (set in the deployment
secriptor) and afaik Sybase does the above as well - but not
WebLogic. I seem to recall Cedric mentioning the above was not
necessary in his personal opinion - though I wonder if that is
BEA's official stand as well.
-krish
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Kenneth D. Litwak
> Sent: Wednesday, September 05, 2001 11:16 PM
> To: [EMAIL PROTECTED]
> Subject: Concurrency in Entity beans
>
>
> As I understand it, according to the spec, an entity bean can be shared
> concurrently by multiple callers, though the container is free to implement
> however it wishes. When multiple callers use the same primary key to access a
> bean, which I think generally results in the same EJBObject being used by all
> callers to get to one entity bean instance, is there ever a time in which,
> rather than all the clients waiting their turn (assuming a transaction
> isolat8ioon requiring exclusive locking) the container would refuse the caller
> and send back an error message becasuse the bean (and the row implicitly) is in
> use and the row or object is locked? Thanks.
>
>
>
> Ken
===========================================================================
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".
