static variables issues

[paul wheaton]

So I'm using weblogic 5.1. I have abunch of static stuff in a BMP entity bean that I loaded from a file. Everything works fine.
Somebody tells be that static variables in a bean are bad, so I shift all this stuff to another class and have my bean call static methods on the class. BOOM! Weblogic crashes with a Dr. Watson error.
What's going on?

[George Brown]

About two months ago I was getting the same thing, WLS crashes with Dr Watson popping up like a Jack-in-the-box. Only I can't remember what the problem was. I recollect fixing it too. I'm sorry, I just read that back and it doesn't solve the problem, but I may be able to find out when I'm back at my desk on Monday. I think that the problem I was having was with some interaction between a JSP and a servlet and I'm fairly sure it was code-related.
As a matter of interest, what was their reason for static variables in a bean being bad?

[paul wheaton]

I don't know why static variables are bad.
Another thing causing the problem could be inheritance. I have two beans. One bean per jar file. Each bean inherits a class I made called EntityBeanAdapter. Weblogic forces me to include the EntityBeanAdapter class in each jar file. My attempts to put both beans in one jar have so far failed.

[George Brown]

I think half the issue here is about persistence.
I'd say that static variables in session beans are possibly questionable from a design POV, in that session beans don't generally represent persistent data. And I'd say that the idea of having an abstract superclass to contain common stuff for entity beans is fine too, even one that includes static vars. However, when you're getting into providing static variables within a BMP entity bean, that's possibly dodgy in this way: a BMP entity bean should need to contain all the necessary methods for repeated passivation (dissociating the bean from the persistent data entity) and re-activation (then associating with another completely different client-requested entity) by the container so even if you are managing persistence with BMP IMO it may not be a good thing to maintain static vars in your entity beans. I suspect it all depends on what the static vars represent anyway.
As an aside, non-final static variables remind me of global variables from the procedural arena which I see as potentially dangerous (depending on their use).

[paul wheaton]

When my bean receives a big chunk of text, the bean needs to proces the data a bit before storing it. Specifically, it needs to find some key words in the document and classify the document. I have a hashtable containing the keywords and the classifications. I want to initialize this table once and use it for every new or updated document. A static hashtable fits perfectly here.
As an alternative, I could store this data in a table and pull it out via jdbc to do the processing. Seems a lot slower, but it looks like there isn't much choice.
I don't want to hard code the data cuz I hope to re-use this code for future projects.

[George Brown]

Could you read the data into your static hashtable with the keywords and classifications in an EntityBeanAdapter-type-of-abstract-class and then subclass that? Or is it too specific to this particular bean?
On the other hand, entity beans and jdbc fit hand-in-glove.
[This message has been edited by George Brown (edited September 30, 2000).]

[George Brown]

umm... what about using the singleton design pattern for the keywords and classifications table?
i liked this article.

[paul wheaton]

I'm using an EntityBeanAdapter that I made. Each of my two beans inherit it. If one bean is loaded, no problem. Both beans and blammo!
In one bean I tried storing the data in a static hashtable. In the other bean I stored the data in a static hashtable in a helper class - a Singleton!
I would like to get that absolute word on the story with static variables in EJB's. Are they frowned apon, or does the spec say they are forbidden? In either case, what about helper classes?

[paul wheaton]

George,
I tried to bring that article up six times. The server must be down.

[George Brown]

an answer from the ejb 1.1 spec, section 18.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.
This rule is required to ensure consistent runtime semantics because while some EJB Containers may use a single JVM to execute all enterprise bean�s instances, others may distribute the instances across multiple JVMs.

Makes sense...
[This message has been edited by George Brown (edited September 30, 2000).]

[paul wheaton]

That is very excellent info! Thanks George! That clears up many things!