Stu Halloway wrote:
> 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.
I don't care about that. They may not have the same cache at all times but each
cache will be appropriately updated before each method call to the bean. In an
extreme case where no updates are made the caches of all the stateless beans
would be the same.
>
>
> 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.
>
That is always the case in using synchronize. To illustrate the point what if I
use a special delegate, lets call it SpecialDelegate. SpecialDelegate would
have one method for each method in the bean. Each method in SpecialDelegate
would be synchronized.
So in my bean I would have,
private SpecialDelegate myDelegate;
public void foo()
{
myDelegate.doFoo();
}
And in SpecialDelegate,
public void doFoo()
{
cache.update();
//do whatever.
}
Note that I am not synchronizing any of the methods in the bean, only methods in
the stateless bean. Why is that any different then using a hashtable (as a data
member in a bean) which has synchronized methods? Note also that I am not doing
this to synchronize mutiple instances of beans, but merely to prevent concurrent
access to the one bean instance. (I don't want another call to update the local
cache when computing foo).
>
> 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".
===========================================================================
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".
