Opinions / Expert Knowledge
I have implemented a working prototype of what I call a "Last one out turn off the light" design.
Here is the design in a nutshell:
Client creates a stateful session bean.
Stateful session bean looks for entity bean with the primary key of the client's IP address. If such an entity bean doesn't exist the session bean creates it. The session bean increments a counter on the entity bean.
When the client closes down it removes the session bean which decrements the entity bean's counter and then tries to remove the entity bean.
The entity bean checks it's counter. If the counter is greater than 0 then the entity does not allow itself to be destroyed.
If the client crashes the session bean is able to decrement the entity bean and then try to remove it. This was no small feat considering that in EJB 1.1 the container neglects to notify the session bean when the container decides to remove it. No one has explained the reason for this 'feature' of 1.1 to me.
Here's the question. Some people on my team argue that we shouldn't do this because there is no conversation going on between the client and the session bean and therefore it does not fit the purpose of a stateful session bean. To me this argument is like saying I shouldn't use a screwdriver to pry the lid off of a paint can because screwdrivers are made for turning screws, not opening paint cans.
Does anyone have an opinion on this? Am I a dangerous rebel who is perverting the EJB spec for my evil purposes? Am I completely off base and missing the whole point here? Does anyone like my idea? (it works very well by the way)
[1666 byte] By [
dubwai] at [2007-9-26 5:43:25]
> I have implemented a working prototype of what I call
> a "Last one out turn off the light" design.
>
> Here is the design in a nutshell:
>
> Client creates a stateful session bean.
>
> Stateful session bean looks for entity bean with the
> primary key of the client's IP address. If such an
> entity bean doesn't exist the session bean creates it.
> The session bean increments a counter on the entity
> bean.
>
> When the client closes down it removes the session
> bean which decrements the entity bean's counter and
> then tries to remove the entity bean.
Yes, like a Object reference counter.
> The entity bean checks it's counter. If the counter
> is greater than 0 then the entity does not allow
> itself to be destroyed.
The Entity-ejb cannot prevent it's self from being destroyed. This is decided by the container, so unless you've re-written that, the Entity-ejb only gets a chance to perform an action first in ejbRemove().
> If the client crashes the session bean is able to
> decrement the entity bean and then try to remove it.
You should be able to call your reference counter from your session beans ejbRemove() method.
> This was no small feat considering that in EJB 1.1
> the container neglects to notify the session bean
> when the container decides to remove it.
Unless this is an implementation fault on your container, this is also achieved by implementing ejbRemove(), in your session bean.
> Here's the question. Some people on my team argue
> that we shouldn't do this because there is no
> conversation going on between the client and the
> session bean and therefore it does not fit the purpose
> of a stateful session bean.
I wouldn't see this as a problem, there is an implicit state [conversation] of connected, this is different from an event/message based model, where this wouldn't hold true, and a state-less session would be used.
> To me this argument is
> like saying I shouldn't use a screwdriver to pry the
> lid off of a paint can because screwdrivers are made
> for turning screws, not opening paint cans.
Tell them it's closer to using a screw-driver to remove a screw cap lid :) and not to take things to literal and remember conversation is a metaphor.
> Does anyone have an opinion on this? Am I
> a dangerous
> rebel who is perverting the EJB spec for my evil
> purposes?
"A rebel, perverting the spec"; probably not! And personally I like to be a little dangerous, myself :)
> Am I completely off base and missing the
> whole point here? Does anyone like my idea?
> (it works very well by the way)
Actually it should do, an object reference counter, is an old solution from which even predated CORBA.
> The Entity-ejb cannot prevent it's self from being
> destroyed. This is decided by the container, so
> unless you've re-written that, the Entity-ejb only
> gets a chance to perform an action first in
> ejbRemove().
Yes, actually it can. If you throw a RemoveException in the Enitity Bean's ejbRemove method calling remove on the remote interface will not remove the entity bean. I've done it successfully.
> You should be able to call your reference counter from
> your session beans ejbRemove() method.
I do.
> Unless this is an implementation fault on your
> container, this is also achieved by implementing
> ejbRemove(), in your session bean.
Look in "Enterprise JavaBeans," Second Edition, Richard Monson-Haefel, O'Reilly, 2000: EJB 1.1 timeouts: "When a timeout occurs the ejbRemove() method is not invoked." I found through experimentation that this also occurs when my client terminates that the session bean is destroyed and the ejbRemove does not get called. I worked around this by adding a timer to the Session bean. When the timer fires, it looks to see if it's reference to the entity bean is still valid. If not a CORBA.OBJECT_NOT_EXIST exception is thrown and it creates a new reference to the enitity bean and decrements it and tries to delete it. I would not believe this is the way EJB 1.1 works if I hadn't seen it for myself.
