Opinions / Expert Knowledge

Question

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)

Answer 1

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.