Critique please (+)
I developed a bean, say to provide sequence numbers.
( for other beans )
This bean is needed virtually everywhere, so
looking it up each time is very verbose. So I developed a class with some static members:
private static InitialContext ic = null;
private static SequenceHome sh = null;
private static HashMap hm = new HashMap();
and static methods which do lazy creation of initialcontext and lazy lookups on home interfaces
and remote references
Remote References are cached in hash map.
There is also static method which returns current
value from desired sequence.
Of course all the lookups and context operations
are done via synchronized methods.
Are there any hidden problems with this approach?
[820 byte] By [
ko5tik] at [2007-9-26 4:43:34]

What kind of EJB is your sequence number generating bean ?
Is it a stateless session bean ?
If so, you are aware that the EJB container creates a pool of stateless session bean instances ? In other words, there will potentially be multiple instances of the same stateless session object.
Okay.
I just thought of sounding that warning considering the a huge pit into my whole team fell a couple of years back doing some thing similar.
If its an entity bean, it seems you have taken care of everything that would noramally come to mind.
However, if I were you, I would wait for more feedback. From this forum and also from else where. But thats just me.
I remember once when some programmer implemented a scheme to generate sequence numbers without giving his scheme enough time to get challenged. The net result was chaos because by the time we realized a hole in the algorithm, some major orders had already been sent to and fulfilled in real time by our fulfillment partner and customers enjoyed some free goods !!
I must call a foul with your approach.
Quoting from Draft2 of the EJB 2.0 spec., section 24.1.2:
An enterprise Bean must not use read/write static fields. Using read-only static fields is
allowed. Therefore, it is recommended that all static fields in the enterprise bean class be
declared as final.
The problem is that in general, EJBs may span multiple JVMs, so mutable statics become meaningless.
-Peris
perisb at 2007-6-29 18:31:15 >

Bean itself has no static fields.
I use separate utility class, which makes
all the work obtaining remote references to
correct instances.
I was worried about static reference to
InitialContext - is there harm to await
if I use the same InitialContext from different ejb-jar's? ( they are in same JVM )
ko5tik at 2007-6-29 18:31:15 >
