Hi!
Lennart Petersson wrote:
> Ok, the mega seller for the last couple of weeks is a box with the jBoss
> EJB server, bundled with some utility programs for only $49, and that
> includes 1 year of support! As you all understand there are more or less
> always a queue of peoples with a jBoss box in their hand.
A.k.a. "JBox".
> Now what happens in this new system when a cashier is scanning an item?
> There is a call to a session bean called MySession. This bean will in
> turn do a findByPrimaryKey to the entity bean Item and when he gots the
> remote interface he will query the bean of its price using method
> getPrice and its description using method getDescription.
>
> The Item bean is configured to use Commit Option A, since there is no
> others interacting with the database. But the consultants that has
> developed the system has now been argueing for a while what it means
> that the ejb server is using pessimistic concurrency? They have read a
> couple of threads on the mailing lists how this works during
> transactions: an entity bean will serialize calls from multiple clients
> that calls from different transactions. But
Some consultants should read less, and think more. Final gain is
probably larger.
> Say that cash register 1 and 2 at the same time scans a jBoss box,
> instanciates a MySession which will call the findByPrimaryKey for the
> jBoss item to get price/description. Will there be 1 or 2 instances of
> the jBoss item?
JBoss uses a one-instance-per-pk caching scheme, a.k.a. pessimistic
concurrency control.
> If one: how will that instance serv the calling clients?
There is one universal EJB rule regardless of implementation: only one
thread at a time may execute a particular EJB instance.
One instance, several concurrent calls: serialized calls (see above)
Several instances, several concurrent calls: calls are processed
concurrently. (should be "concurrently", at least on single-processor
system).
> Will they be handled one after the other?
See above.
> What about the readonly flag
> that you may set on a bean, how will that change the situation?
The readonly flag is a proprietary one that indeed will allow several
transactions to execute an EJB instance concurrently, hence
circumventing the above. This may only be used if the data is static, or
if it is ok that it is non-static but updated into the EJB cache at
regular intervals.
But you are asking somewhat irrelevant questions IMHO. What is probably
more relevant are:
* Are different transactions/clients accessing the same entity/pk
concurrently? (without this the above is meaningless)
* Are the transactions short? If so, the penalty of serialized calls is
close to zero, and hence unimportant
HTH,
Rickard
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
