Stu Halloway wrote: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 would have no problem with that. It just means that multiple copies of the
cache would exist. If my cache isn't too large I may not mind that. As an
extreme case imagine that the database table being cached never changes. Upon
creation the stateless bean would download the table into some datastructure
representing the cache.
Even with updates it wouldn't matter that I have multiple copies of the table
existing in multiple beans. Each stateless bean would update itself in each
method call. So each bean would have a proper view of the table at the time of
the call.
Note also that I am not using synchronize to synchronize the instances but
merely to synchronize or make multitthread safe my local copy of the table.
But upon futher thought I wouldn't need to use synchronize in the stateless
bean. I can probably use a "select for update to achieve the same affect.
Here is a very simple example of what I am talking about. I will cache one
number in my stateless bean (a ridiculous thing to do of course, but I am just
trying to illustrate the point. I could do the same thing with a database table
but it would require more code)
by stateless bean would have a member variable
private int myNumber;
also
public void updateMySelf()
{
//Using a connection
// select x from someTable for update and then eventually do.
myNumber = resultSet.getInt(1);
}
Now in any method call of the bean.
public void aMethod()
{
updateMySelf();
//do whatever using myNumber.
}
So I think this would be OK even with multiple concurrent access to this bean
instance and even if multiple copies of the bean exists.
The same can be done if instead of caching on number you cached a whole database
table. In each method call you would read in any updates since your last call
to update. I want get into all the details. The point is that you would avoid
reading in the whole table by reading in only the updates to the table. (The
database would have to keep track in another table of those updates).
This might be a good solution in the case where a table is updated rather
infrequently but is accessed often.
Read on about a further response to the synchronization issue.
>
>
> 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.
This can happen with pessimistic concurrency as well.
Take the case of some data structure that must be synchronized. For example the
addElement of vector is synchronized. Surely it is OK to use a vector as a
member variable of a bean? OK now imagine that I create my own data structure
to be used in the bean. Instead of synchronizing the methods suppose that I wrap
the calls in a synchronized block (which may be a dumb thing to do). So let's
say my class is SuperVector and it has a method addElement. Instead of the
method itself being synchronized suppose that I do the following any time I call
addElement
synchronized(this)
{
superVector.addElement(obj);
}
That would have the same effect as if the addElement method were synchronized.
(Assuming that I only use SuperVector in this bean and that I always wrap the
calls.
So if this can cause a problem then any data structure including many jdk
supplied structures would cause a problem.
So my point is that synchronize isn't always bad.
>
>
> 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".
