** Okay guys, I've updated this email with a decent example I hope ** > Access to each session bean instance is serialized, but the spec > doesn't specifically allow you to say there may only be one instance > of a particular session bean class.
** so in otherwords, pretty much it achieves the effect I wanted with
little effort... that's kinda nice... and it does this no matter what
isolation/transaction level I request or would you recommend a few
settings?
> Access to entity beans is also
> serialized and you can be certain that, in a a given app server
> instance (neglecting clustering issues), there's only one instance of a
> particular entity bean class + primary key.
okay, so if I have two servlets, if I change the value of say foo of
an entity, the other servlet upon say reading the value foo will
see the new value automagically? Even if I don't do another finder
call?
> It sounds to me like your
> talking about something much more like an entity. You can still get
> the guarantee you're looking for if you access the entity through a
> session bean, but the guarantee comes from the properties of the
> entity bean, not the session bean.
Well I thought of using the session bean because I'm kinda trying to
perform an action that has three steps:
1) check balance
2) deduct from account
3) credit new account
But the problem comes not from making sure there's only one copy, but
the (I think you call it) a race condition.
Say $5 in bank account A, and we want to pay account B $4 and account C
$3.
Servlet 1:
Task: Pay Account B $4 from Account A
Servlet 2:
Task: Pay Account C $3 from Account A
Servlet 1:
1) Check account balance
Yup $5 is more than $4
Servlet 2:
1) Check account balance
Yup $5 is more than 3
Servlet 1:
2) Deduct $4 from Acct A
Servlet 2:
2) Deduct $3 from Account A (must be okay since the check was okay in
step 1)
Servlet 1:
3) Credit Acct B $4
Servlet 2:
3) Credit Acct C $3
End result, balance on Acct A is -$2 even though we checked to make sure
the
entity had the correct balance. Yes the ending balance is correct too!
But
the end result is _undesirable_ since we should have prevented Servlet 2
from
completing execution and throw an exception.
So I hope to make the task Synchronized such that Servlet 2 is Blocked
until
Servlet 1's transfer task is complete such that the following is
observed
Servlet 1:
Task: $4 from A to B
Servlet 2:
Task: $3 From A to C
Servlet 1:
Call Session Bean to Xfer funds
stuff happens
1) ... ok
Servlet 2:
Call Session Bean to Xfer Funds
1) ... can't check yet, the Session bean is busy
with session 1's request
-- Blocked --
Servlet 1:
.. more stuff happens...
2) ... deduct
3) ... deposit
-- Finish --
Servlet 2:
-- Unblocked --
1) .. continue... check... too little money
** Throw Exception
-- Finish --
So yes in both cases the Entity reacts as programmed, but it's the
Session Bean I hope to change the behavior of. Is the desired
behavior the default way of execution or do I have to do something
special?
> Does that help any?
yes it does, and don't get me wrong, I trust what you're saying, but
I just ask a little more to make sure I understand all the little
"unsaid" details ;)
Thanks again!
Jeff
smime.p7s
Description: S/MIME Cryptographic Signature
