Dan,
> Suppose for example that you want to cache a database table using
> a stateless
> bean. When the bean instance is created (no relationship to
> calling the create
> method) it loads in the rows of the table into some structure,
> let's just say a
> vector. All updates, deletes or inserts to the table are stored
> in another table
> with a sequence number. Whenever a method is called the "Modify"
> table is read
> by the stateless bean and appropriate changes are made to the
> vector. I would
> need to make sure that updates to the vector are done in a
> synchonous way so I
> might use some synchronization primitives here. But note that I am only
> interested in this one bean instance. Each stateless bean would
> have it's own
> copy of the database table and I would only be interested in each
> stateless bean
> in isolation.
1. How is your cacheing bean going to work if the container distributes
beans across VMs? Different clients will get different versions of the
cache.
2. The container will itself be using sychronization primitives & resource
manager locks on your behalf. If you start explicitly locking things as
well, you are going to have to be very careful to avoid deadlock. Since you
shouldn't rely on the particular implementation of the container, it may be
difficult to avoid the case where bean A holds a container lock and is
waiting on your lock, and bean B holds your lock and is waiting on a
container lock.
BTW, my last four posts to this list never made it. Are we being moderated?
Am I not making the grade? I promise to quit saying "Roger Sessions rocks!"
:-)
Stuart Halloway
DevelopMentor
http://www.develop.com/hp/halloway
===========================================================================
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".
