Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Loading BusinessDelegates in Servlet Context?  RSS feed

 
Matt Kim
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

I'm creating a web app and I've loaded my Business Delegates to access the EJB container into the Servlet Context. Is this correct in doing this?

Here's my problem. When first logging in, everything works nicely. However, when the session times out and I try to re-log in, I get the following error:

java.rmi.NoSuchObjectException: Could not activate; failed to restore state; CausedByException is:
D:\jboss-3.2.3\server\default\tmp\sessions\AccountManager-dueq6rvd-5\dueq6yve-b.ser (The system cannot find the file specified)
at org.jboss.ejb.plugins.AbstractInstanceCache.get(AbstractInstanceCache.java:116)
at org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invoke(StatefulSessionInstanceInterceptor.java:210)
at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:84)
at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:267)
at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:128)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191)
at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)
at org.jboss.ejb.StatefulSessionContainer.internalInvoke(StatefulSessionContainer.java:416)
at org.jboss.ejb.Container.invoke(Container.java:700)
at sun.reflect.GeneratedMethodAccessor78.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546)
at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:367)
at sun.reflect.GeneratedMethodAccessor77.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)
at sun.rmi.transport.Transport$1.run(Transport.java:148)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
at java.lang.Thread.run(Thread.java:534)

Your help is appreciated.

Regards,
Matt
 
Alex Sharkoff
Ranch Hand
Posts: 209
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Matt,

Looks like you're using stateful session beans. Remember that stateful session beans can time out as well (first they get passivated and then if not accessed for some time they get removed).

Please refer to http://www.coderanch.com/t/159223/java-EJB-SCBCD/certification/Stateful-session-bean-not-activate

Hope it helps
 
Matt Kim
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Alex, that does help.

Now my question is, what's the best way to solve this problem? Convert everything to a stateless session bean or changing the <max-bean-life> value (increase or decrease?) in the jboss.xml.

Regards,
Matt
 
Alex Sharkoff
Ranch Hand
Posts: 209
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Matt,

ServletContext can be used to store global variables (i.e. variables that can be used by all users of the application, eg, db connection pool).

At the same time a stateful session bean is used to store the conversation state bw one user and the application (eg, shopping application: user logs into the system, starts "buying spree" -> stateful session bean is used to remember what the user put into his/her shopping cart -> user buys/cancels his/her order -> stateful session bean removed).

As you can see it just does not make sense to use one stateful session bean for all users (unless you need to keep a track of what all users who logged into the system did, which is highly unlikely - if you did have such a condition for your application you'd rather save "user in the system" info into the db so that it becomes persistent and can be queried at any time, even when the application restarted.)

I am not aware of your app requirements. However, from what has been said I can conclude that you do not need to use stateful session beans, but rather use stateless session beans. At the same time you might not need to use ejb at all. You could search Google to get some ideas on this topic (eg, search for "do i need to use ejb in my application").


Hope it helps.
 
Matt Kim
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Alex, that's very helpful.

The reason I used stateful session beans is to store the Entity Beans' Home interfaces into instance variables so as not to constantly need to recall it upon invocation of different methods.

The Business Delegates that access these Session beans are stored in my Servlet Context to behave like some form of DB pool for all the clients to use.

Is this not correct, or not a good way of designing my beans?

Regards,
Matt
 
Alex Sharkoff
Ranch Hand
Posts: 209
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Matt,

You can achieve it by simply storing eb's home interfaces (i.e. their stubs if using remote home) in the ServletContext using it as a cache. As far as I understand you want to avoid the situation where every call to the eb's home results in the jndi lookup.

You might want to think about other techniques for achieving similar effect (eg, Factory for every eb type that has a private static member that references a eb's home interface. This member is lazy loaded and therefore, the jndi lookup is only performed once. Then you could extend the use of Factory so that the client never creates / finds entity beans directly but rather through the factory -> all logic is in one place -> encapsulation)

Hope it helps,


[ May 22, 2004: Message edited by: Alex Sharkoff ]
 
Matt Kim
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the help Alex!
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!