That is the error you get if you are trying to access the same instance of a stateful session bean (SSB) with more than one thread.
Our reference to the stateful session bean is stored in the HttpSession object and passed to a stateless session facade. In our scenario the error occurs because we are using framesets in the web tier and up to three threads may be trying to access our SSB at once.
When the header and middle part of a web page request information from the SSB via the session facade, the container will then make three instances of the session facade available to serve each call but each of these instances is trying to access the same instance of the stateful session bean.
A quick search on Google (as always) showed this is a common problem but I was not able to find a quick solution. One of my colleagues suggested that I should try “synchronization” which I did with what seems until now a success.
In my session facade bean, I surround all accesses to the stateful session bean with synchronization blocks, locking on the SSB. This will prevent more than one thread accessing the SSB; once a thread has entered the SSB any additional threads will be queued.
public void submitText(TextTo text, TextSessionLocal textLocal) {
log.debug("ENTER submitText(TextTo text, TextSessionLocal textLocal): "+text);
synchronized (textLocal) {
//set message data in SSB
textLocal.setMsgTitle(text.getMsgTitle());
.... more code
}
log.debug("EXIT submitText(TextTo text, TextSessionLocal textLocal));
}
One might ask what impact this may have on the performance. Because it will only be one single user that will be accessing the same instance of a SSB I don’t think the performance will be detoriated by much but later stress testing will show more.
Stateful session beans should be avoided if possible. Especially if purpose of it is for storing some HttpSession data, like intermediate steps in a shopping process. It is recommended then to store the partial information in the HttpSession and as a last step to use a stateless session bean to perform the business logic. Well, maybe next time 😉
Update 05/11/03
This QA about EJBs article from Sun is very related
Category: Java
java.io.Reader issues
I have developed an XML converter that is based on the Castor framework. It is quite simple as it takes certain Java objects (beans, collections and maps) and returns an XML representation.
Actually I have implemented it so it returns an InputSource which goes well with the next step in the process, the Xalan transformation.
The problem I am having is that the InputSource can only be used once whereas we would like to use it multiple times. At least once to log the converted XML and second time for the XSLT. As soon as the input source has been used for logging purposes of the XML, the internal reader is empty and I have not found any way of resetting it.
I see two solutions. Either redesign the XMLConverter to store the XML content internally in a different way or write a utility that copies the content of one reader to another reader, while it outputs the content.
And all that Work
I wish the title was saying ‘And all that Jazz‘ but it is not because it is Saturday noon and I am working. At least it is from my own bed and with Ginger next to me.
The annoying thing with the recent project has been lack of design and the scope of technologies that are in use simultaneously. I have no problems working with a couple of those technologies but all at once takes away some of the concentration.
We are using an unorthodox mix of Data Access Objects (DAOs) and EJB 2.0. What we learned was that you have to watch out not using both technologies to update your precious data base tables. If you do, the EJB container locks the tables and your DAO methods start failing and rolling back to left and right.
I have previously used XDoclet to help with the formalities of EJB 2.0 and Struts framework. This time we have not taken the time (pun intended) to set up XDoclets so it is a pain every time the data model changes or the EJB implementation is updated and the interfaces need to be updated accordingly. At this point of the project, nearly end, it doesn’t make sense to start adding XDoclet tags and modifying the Ant build scripts but I have made a mental note to use XDoclets from the beginning next time.
The front-end is prepared for internalization and device independent rendering by using XML/XSL. I found that the Castor frame work is great for converting your complex Java objects to an XML representation. Later Xalan is used for the XSL transformations. One trick from the big bag of tricks is to have dynamic XSL style sheets by using JSPs. This allows us to use constants from our standard Java interfaces and to internalize our pages with the help of JSTL.
Axis framework is a great help for setting up web services for cross application wide services and sending those SOAP calls.
There has not been as much JUnit testing as we first anticipated due to lack of time. Instead of writing JUnit suits for all classes I have only written tests for core utilities that are used by several modules in the application. It was quicker to write the tests and making sure the utilities pass than to face kludgy code that would need thorough debugging.
The mix of everything is fun but just when you are getting groovy with the required on-the-fly design and UML modeling you are interrupted by some nasty JavaScript debugging or even worse, CSS problems.
I wish we find the resources to have a couple of front end developers (scary, MS Word just highlighted the last word because it found the same entry in my Outlook contacts, too smart for my liking).