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]
# 1

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.

neville_sequeira at 2007-6-29 18:31:15 > top of Java-index,Enterprise & Remote Computing,Enterprise Technologies...
# 2
No, it's entity. The idea is to have just a singleton class which has static reference to InitialContext and knows hot to get correct sequence bean.
ko5tik at 2007-6-29 18:31:15 > top of Java-index,Enterprise & Remote Computing,Enterprise Technologies...
# 3

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 !!

neville_sequeira at 2007-6-29 18:31:15 > top of Java-index,Enterprise & Remote Computing,Enterprise Technologies...
# 4

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 > top of Java-index,Enterprise & Remote Computing,Enterprise Technologies...
# 5
Take a look at this example, it seems related: http://www.theserverside.com/patterns/thread.jsp?thread_id=220
swatdba at 2007-6-29 18:31:15 > top of Java-index,Enterprise & Remote Computing,Enterprise Technologies...
# 6

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 > top of Java-index,Enterprise & Remote Computing,Enterprise Technologies...
# 7
Nothing comes to mind in terms of a problem with respect to have a static reference to an InitialContext. I have done the same in some places without any issues.
neville_sequeira at 2007-6-29 18:31:15 > top of Java-index,Enterprise & Remote Computing,Enterprise Technologies...