Caching data in stateful sesion bean

Hi,
Is it a good idea to cache user dependent data in stateful session
beans because of repeated hits to the same data?
Is there a better way to do this?
Thanks
Sandhya

The answer depends. You have to ask and answer these questions...
how much data needs to be cached per session
must the session data remain in existence after the session is closes
what are your response time requirements
what are the maximum number of users that you will need to support
Some options are
- Statefull session beans
- Cookies
- Stuff the data into the http session object
- Caching session information in a singleton (more complicated in a cluster)
All of these options are good ones. Apply the write one to your specific
instance.
Good luck
"Sandhya S Suku" <[email protected]> wrote in message
news:[email protected]..
Hi,
Is it a good idea to cache user dependent data in stateful session
beans because of repeated hits to the same data?
Is there a better way to do this?
Thanks
Sandhya

Similar Messages

Caching data in Omni Portlets

If i insert new data into my database it takes a while before my omni portlet picks it up(even if i refresh the portlet), i have turned off page level caching, but this doesnt seem to solve the problem - is there any way to fix this?
Also occasionaly my portlet errors with : "Error in executing Query : [Io exception: Connection reset by peer: socket write error]" but the database is still up. Any ideas?
Thanks

The answer depends. You have to ask and answer these questions...
how much data needs to be cached per session
must the session data remain in existence after the session is closes
what are your response time requirements
what are the maximum number of users that you will need to support
Some options are
- Statefull session beans
- Cookies
- Stuff the data into the http session object
- Caching session information in a singleton (more complicated in a cluster)
All of these options are good ones. Apply the write one to your specific
instance.
Good luck
"Sandhya S Suku" <[email protected]> wrote in message
news:[email protected]..
Hi,
Is it a good idea to cache user dependent data in stateful session
beans because of repeated hits to the same data?
Is there a better way to do this?
Thanks
Sandhya

Problem using application client for local stateful session bean

Hi,
I have deployed a local stateful session bean in Sun J2EE 1.4 application server.
On running the applclient for the stateful session bean application client i get the following error:
Warning: ACC006: No application client descriptor defined for: [null]
cant we use application client for local stateful session beans. becoz the application runs smoothly when i changed the stateful sesion bean to remote.

Hi,
No, an ejb that exposes a local view can only be accessed by an ejb or web component packaged within the same application. Parameters and return values for invocations through the ejb local view are passed by reference instead of by value. That can't work for an application client since it's running in a separate JVM.
--ken

Stateful Session Beans are not passivated / serialized when cache idle time

Technology: Sun Application Server version 7.0.0_01; JDK 1.4.1; developed on Windows 2000; Tested on Sun Solaris.
Initial error on Sun Solaris:
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr: Exception in thread "service-j2ee-25" org.omg.CORBA.OBJ_ADAPTER: vmcid: SUN minor code: 1015 completed: No
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.POA.GenericPOAServerSC.preinvoke(GenericPOAServerSC.java:389)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.POA.ServantCachePOAClientSC.initServant(ServantCachePOAClientSC.java:112)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.POA.ServantCachePOAClientSC.setOrb(ServantCachePOAClientSC.java:95)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream_1_0.createDelegate(CDRInputStream_1_0.java:760)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream_1_0.internalIORToObject(CDRInputStream_1_0.java:750)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream_1_0.read_Object(CDRInputStream_1_0.java:669)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:890)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:884)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream.read_abstract_interface(CDRInputStream.java:307)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.IIOPInputStream.readObjectDelegate(IIOPInputStream.java:228)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.IIOPInputStream.readObjectOverride(IIOPInputStream.java:381)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at java.io.ObjectInputStream.readObject(ObjectInputStream.java:318)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.enterprise.iiop.IIOPHandleDelegate.getStub(IIOPHandleDelegate.java:58)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.enterprise.iiop.IIOPHandleDelegate.readEJBObject(IIOPHandleDelegate.java:38)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.ejb.portable.HandleImpl.readObject(HandleImpl.java:91)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.IIOPInputStream.readObject(Native Method)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.IIOPInputStream.invokeObjectReader(IIOPInputStream.java:1298)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.IIOPInputStream.inputObject(IIOPInputStream.java:908)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:261)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:247)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.se.internal.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:209)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:981)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.iiop.CDRInputStream.read_value(CDRInputStream.java:287)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.sun.corba.ee.internal.javax.rmi.CORBA.Util.copyObject(Util.java:598)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at javax.rmi.CORBA.Util.copyObject(Util.java:314)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.telstra.nodeman.ejb._NodeMaint_Stub.getHandle(Unknown Source)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.telstra.nodeman.arch.NMAViewBeanProxy.checkBeans(NMAViewBeanProxy.java:631)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.telstra.nodeman.view.html.NMAStandardButton.handleRequest(NMAStandardButton.java:143)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.telstra.nodeman.arch.NMAViewBeanBase.handleRequest(NMAViewBeanBase.java:1573)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.jato.view.ViewBeanBase.dispatchInvocation(ViewBeanBase.java:824)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.jato.view.ViewBeanBase.invokeRequestHandlerInternal(ViewBeanBase.java:637)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.jato.view.ViewBeanBase.invokeRequestHandler(ViewBeanBase.java:595)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.jato.ApplicationServletBase.dispatchRequest(ApplicationServletBase.java:772)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.jato.ApplicationServletBase.processRequest(ApplicationServletBase.java:446)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.jato.ApplicationServletBase.doPost(ApplicationServletBase.java:324)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.telstra.nodeman.view.ViewServlet.doPost(ViewServlet.java:243)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardWrapperValve.invokeServletService(StandardWrapperValve.java:720)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardWrapperValve.access$000(StandardWrapperValve.java:118)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardWrapperValve$1.run(StandardWrapperValve.java:278)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at java.security.AccessController.doPrivileged(Native Method)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:274)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:212)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:203)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.ias.web.connector.nsapi.NSAPIProcessor.process(NSAPIProcessor.java:158)
[10/Aug/2004:08:04:57] WARNING (17227): CORE3283: stderr:      at com.iplanet.ias.web.WebContainer.service(WebContainer.java:598)
The above error caused the server to use all available memory and required a reboot to proceed.
Subsequent testing against the Sun Appliucation Server 7 on Windows 2000 dev environment using the Sun Studio IDE for debugging and trace statements inserted in the code indicate that the Application Server is removing the Stateful Session Beans when they time out without an ejbPassivate event and without serializing the beans to the data-store. cache-idle-timeout-in-seconds set to 180 and removal-timeout-in-seconds set to 1800.
The server.log indicates that the beans are timing out:
[19/Aug/2004:18:15:10] WARNING ( 1664): [NRU-com.telstra.nodeman.ejb.AddressMaintBean]: IdleBeanCleanerTask finished after removing 2 idle beans
Trace statements inserted in ejbPassivate do not appear in the log.
It is my understanding that the above timeout should have caused an ejbPasssivate and serialization of the beans.
The beans have been validated using Sun Java Studio Enterprise 6 with 'EJB validate'.
My reading of the problem is that the beans are not being serialized and the error occurs when the application attempts to reference (getHandle) the bean after timeout.
Any suggestions would be appreciated.

Thanks Thorick.
I am using NRU caching. WL 7.0 SP2.
I have not defined idle-timeout-seconds in my weblogic-ejb-jar.xml. As I understand
the default value for this is 600secs. So the ejbs should be removed after this
time. Below is the
weblogic-ejb-jar.xml that I am using.
<!DOCTYPE weblogic-ejb-jar PUBLIC '-//BEA Systems, Inc.//DTD WebLogic 7.0.0 EJB//EN'
'http://www.bea.com/servers/wls700/dtd/weblogic-ejb-jar.dtd'>

<weblogic-ejb-jar>
<weblogic-enterprise-bean>
<ejb-name>Cart</ejb-name>
<stateful-session-descriptor>
<stateful-session-clustering>
<home-is-clusterable>true</home-is-clusterable>
<replication-type>InMemory</replication-type>
</stateful-session-clustering>
</stateful-session-descriptor>
<transaction-descriptor>
     <trans-timeout-seconds>
          60
     </trans-timeout-seconds>
</transaction-descriptor>
<jndi-name>CartHome</jndi-name>
</weblogic-enterprise-bean>
</weblogic-ejb-jar>
"thorick" <[email protected]> wrote:
>
The idle-timeout-seconds property controls the timeout/removal behavior.
which stateful session cache type are you using ? LRUCache or NRUCache

Caching data with Entity Bean

Hello,
I am performing some tests concerning the benefit of caching data with Entity Bean.
Here is the case :
I have an Entity Bean with a business method getName() to retrieve a name field in the EJB.
I understand that in order to cach data, I have to set the NOT_SUPPORTED transaction attr for this method. In this way, when this method is called, the ejbReload() is not called and the data is retreived from the EJB ready instance (and not from the database).
Is it true and is it the good way to use the cach mechanism ?
Now if we consider that this instance is the only one in the ready stage, and it is never pooled (it seems so !), what about a modification of the database from a tier (or from an other EB instance)? The Entity Bean is not able to see this modification seence it does not call the ejbLoad method.
Is there a way to force an Entity Bean to be periodically polled in order to recover data from the data store when activated ?
Thanks in advance,
Thierry

No, This is wrong way of doing what you want. Most of the application servers provide various configuration settings for this. Eg. caching mechanism, interval on when to call ejbLoad and ejbStore, read only beans. You have to check the documentation for this.
--Ashwani

Accessing the same stateful session bean from multiple clients in a clustered environment

I am trying to access the same stateful session bean from multiple
          clients. I also want this bean to have failover support so we want to
          deploy it in a cluster. The following description is how we have tried
          to solve this problem, but it does not seem to be working. Any
          insight would be greatly appreciated!
          I have set up a cluster of three servers. I deployed a stateful
          session bean with in memory replication across the cluster. A client
          obtains a reference to an instance of one of these beans to handle a
          request. Subsequent requests will have to use the same bean and could
          come from various clients. So after using the bean the first client
          stores the handle to the bean (actually the replica aware stub) to be
          used by other clients to be able to obtain the bean. When another
          client retrieves the handle gets the replica aware stub and makes a
          call to the bean the request seems to unpredictably go to any of the
          three servers rather than the primary server hosting that bean. If the
          call goes to the primary server everything seems to work fine the
          session data is available and it gets backed up on the secondary
          server. If it happens to go to the secondary server a bean that has
          the correct session data services the request but gives the error
          <Failed to update the secondary copy of a stateful session bean from
          home:ejb20-statefulSession-TraderHome>. Then any subsequent requests
          to the primary server will not reflect changes made on the secondary
          and vice versa. If the request happens to go to the third server that
          is not hosting an instance of that bean then the client receives an
          error that the bean was not available. From my understanding I thought
          the replica aware stub would know which server is the primary host for
          that bean and send the request there.
          Thanks in advance,
          Justin


          If 'allow-concurrent-call' does exactly what you need, then you don't have a problem,
          do you?
          Except of course if you switch ejb containers. Oh well.
          Mike
          "FBenvadi" <[email protected]> wrote:
          >I've got the same problem.
          >I understand from you that concurrent access to a stateful session bean
          >is
          >not allowed but there is a
          >token is weblogic-ejb-jar.xml that is called 'allow-concurrent-call'
          >that
          >does exactly what I need.
          >What you mean 'you'll get a surprise when you go to production' ?
          >I need to understand becouse I can still change the design.
          >Thanks Francesco
          >[email protected]
          >
          >"Mike Reiche" <[email protected]> wrote in message
          >news:[email protected]...
          >>
          >> Get the fix immediately from BEA and test it. It would be a shame to
          >wait
          >until
          >> December only to get a fix - that doesn't work.
          >>
          >> As for stateful session bean use - just remember that concurrent access
          >to
          >a stateful
          >> session bean is not allowed. Things will work fine until you go to
          >production
          >> and encounter some real load - then you will get a surprise.
          >>
          >> Mike
          >>
          >> [email protected] (Justin Meyer) wrote:
          >> >I just heard back from WebLogic Tech Support and they have confirmed
          >> >that this is a bug. Here is their reply:
          >> >
          >> >There is some problem in failover of stateful session beans when its
          >> >run from a java client.However, it is fixed now.
          >> >
          >> >The fix will be in SP2 which will be out by december.
          >> >
          >> >
          >> >Mike,
          >> >Thanks for your reply. I do infact believe we are correctly using
          >a
          >> >stateful session bean however it may have been misleading from my
          >> >description of the problem. We are not accessing the bean
          >> >concurrently from 2 different clients. The second client will only
          >> >come into play if the first client fails. In this case we want to
          >be
          >> >able to reacquire the handle to our stateful session bean and call
          >it
          >> >from the secondary client.
          >> >
          >> >
          >> >Justin
          >> >
          >> >"Mike Reiche" <[email protected]> wrote in message
          >news:<[email protected]>...
          >> >> You should be using an entity bean, not a stateful session bean
          >for
          >> >this application.
          >> >>
          >> >> A stateful session bean is intended to be keep state (stateful)
          >for
          >> >the duration
          >> >> of a client's session (session).
          >> >>
          >> >> It is not meant to be shared by different clients - in fact, if
          >you
          >> >attempt to
          >> >> access the same stateful session bean concurrently - it will throw
          >> >an exception.
          >> >>
          >> >> We did your little trick (storing/retrieving handle) with a stateful
          >> >session bean
          >> >> on WLS 5.1 - and it did work properly - not as you describe. Our
          >sfsb's
          >> >were not
          >> >> replicated as yours are.
          >> >>
          >> >> Mike
          >> >>
          >> >> [email protected] (Justin Meyer) wrote:
          >> >> >I am trying to access the same stateful session bean from multiple
          >> >> >clients. I also want this bean to have failover support so we want
          >> >to
          >> >> >deploy it in a cluster. The following description is how we have
          >tried
          >> >> >to solve this problem, but it does not seem to be working. Any
          >> >> >insight would be greatly appreciated!
          >> >> >
          >> >> >I have set up a cluster of three servers. I deployed a stateful
          >> >> >session bean with in memory replication across the cluster. A client
          >> >> >obtains a reference to an instance of one of these beans to handle
          >> >a
          >> >> >request. Subsequent requests will have to use the same bean and
          >could
          >> >> >come from various clients. So after using the bean the first client
          >> >> >stores the handle to the bean (actually the replica aware stub)
          >to
          >> >be
          >> >> >used by other clients to be able to obtain the bean. When another
          >> >> >client retrieves the handle gets the replica aware stub and makes
          >> >a
          >> >> >call to the bean the request seems to unpredictably go to any of
          >the
          >> >> >three servers rather than the primary server hosting that bean.
          >If
          >> >the
          >> >> >call goes to the primary server everything seems to work fine the
          >> >> >session data is available and it gets backed up on the secondary
          >> >> >server. If it happens to go to the secondary server a bean that
          >has
          >> >> >the correct session data services the request but gives the error
          >> >> ><Failed to update the secondary copy of a stateful session bean
          >from
          >> >> >home:ejb20-statefulSession-TraderHome>. Then any subsequent requests
          >> >> >to the primary server will not reflect changes made on the secondary
          >> >> >and vice versa. If the request happens to go to the third server
          >that
          >> >> >is not hosting an instance of that bean then the client receives
          >an
          >> >> >error that the bean was not available. From my understanding I
          >thought
          >> >> >the replica aware stub would know which server is the primary host
          >> >for
          >> >> >that bean and send the request there.
          >> >> >
          >> >> >Thanks in advance,
          >> >> >Justin
          >>
          >
          >

Error in updating secondary stateful session bean

          Hi all,
          I have set up a cluster of 2 managed servers with WebLogic 6.1. I have a
          stateful session bean and several stateless session beans. the stateful
          session bean keeps user info and limited cached objects, all are
          serializable. it seems working fine, even after killing any one of the
          servers, as long as one is alive. a java application client creates a
          stateful session bean first, then calls stateless session beans with the
          remote interface of the stateful bean as a method parameter. No problem
          when stateful session bean is created. However, each stateless bean method
          generates the following error message if I turn the debug on (level 64). No
          exception stack traces, and all methods execute successfully.
          <Error> <EJB> <Failed to update the secondary copy of a stateful session
          bean from home:clientsession>
          I wonder what causes the error, and why it tries to update the stateful
          session bean. in all stateless session beans, only read into the stateful
          bean.
          Thank you,
          Fujin


This has been fixed in WLS 6.1 SP2.
          jagdip Talla wrote:
          > Hi Fujin,
          > please let me know, if u were able to solve the problem..
          >
          > hi guys,
          > appreciate if you could give me some clues
          > how to solve this problem ?
          >
          > i hv 2 WLS instances in a cluster,
          > when one server instance is shut down, i keep getting these errors ?
          > is it normal ?
          > <Feb 19, 2002 2:57:53 PM SGT> <Error> <EJB> <Failed to update the secondary copy of a stateful session bean from home:ejb/xyzrel1_2/xxxxHome>
          >
          > appreciate if u can let me know, if u could solve it..?
          >
          > thanks n regads
          > jagdip
          Rajesh Mirchandani
          Developer Relations Engineer
          BEA Support

Binding stateful EJB bean

Hi,
I have a problem binding EJB bean (Stateful bean). Bean have two business methods:
SendPacketToTRSM and GetData
When I invoke SendPacketToTRSM method from process, application server create first instance of bean and invoke method SendPacketToTRSM
Next I invoke GetData method in process, application server create second instance of bean and invoke method GetData.
Every time, when I invoke method, application server create new instance of bean and don't remove it.
Application server after passivation remove instance of bean from container.
Environment: BPEL 10.0.2(OC4J), patch 4369818, 4406640, 4496111
EJB bean on JBoss 4.0.2
The following wsdl EJB binding:
<?xml version="1.0" ?>
<definitions targetNamespace="http://xmlns.unizeto.pl/TRSMBPEL"
xmlns:tns="http://xmlns.unizeto.pl/TRSMBPEL"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:format="http://schemas.xmlsoap.org/wsdl/formatbinding/"
xmlns:ejb="http://schemas.xmlsoap.org/wsdl/ejb/"
xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/"
xmlns="http://schemas.xmlsoap.org/wsdl/">

<message name="SendPacketToTRSMRequestMessage">
<part name="sender" type="xsd:int"/>
<part name="bufferToTRSM" type="xsd:string"/>
</message>
<message name="SendPacketToTRSMResponseMessage">
<part name="result" type="xsd:int"/>
</message>
<message name="GetDataRequestMessage">
</message>
<message name="GetDataResponseMessage">
<part name="result" type="xsd:string"/>
</message>
<message name="RemoveRequestMessage">
</message>
<message name="RemoveResponseMessage">
</message>
<message name="CreateRequestMessage">
</message>
<message name="CreateResponseMessage">
</message>

<portType name="TRSMService">
<operation name="SendPacketToTRSM">
<input name="SendPacketToTRSMRequest" message="tns:SendPacketToTRSMRequestMessage"/>
<output name="SendPacketToTRSMResponse" message="tns:SendPacketToTRSMResponseMessage"/>
</operation>
<operation name="GetData">
<input name="GetDataRequest" message="tns:GetDataRequestMessage"/>
<output name="GetDataResponse" message="tns:GetDataResponseMessage"/>
</operation>
<operation name="Remove">
<input name="RemoveRequest" message="tns:RemoveRequestMessage"/>
<output name="RemoveResponse" message="tns:RemoveResponseMessage"/>
</operation>
<operation name="Create">
<input name="CreateRequest" message="tns:CreateRequestMessage"/>
<output name="CreateResponse" message="tns:CreateResponseMessage"/>
</operation>
<operation name="SSCDAuthorizedForget">
</portType>

<binding name="EJBBinding" type="tns:TRSMService">
<ejb:binding/>
<format:typeMapping encoding="Java" style="Java">
<format:typeMap typeName="xsd:int" formatType="int"/>
<format:typeMap typeName="xsd:string" formatType="java.lang.String"/>
</format:typeMapping>
<operation name="SendPacketToTRSM">
<ejb:operation
methodName="SendBase64PacketToTRSM"
parameterOrder="sender bufferToTRSM"
interface="remote"
returnPart="result"/>
<input name="SendPacketToTRSMRequest"/>
<output name="SendPacketToTRSMResponse"/>
</operation>
<operation name="GetData">
<ejb:operation
methodName="GetBase64Data"
parameterOrder=""
interface="remote"
returnPart="result"/>
<input name="GetDataRequest"/>
<output name="GetDataResponse"/>
</operation>
<operation name="Remove">
<ejb:operation
methodName="remove"
interface="remote"/>
</operation>
<operation name="Create">
<ejb:operation
methodName="create"
interface="home"/>
</operation>
</binding>

<service name="TRSMService">
<port name="EJBPort" binding="tns:EJBBinding">
<ejb:address className="pl.unizeto.pki.des.ssp.trsmd.TRSMDRemoteHome"
jndiName="pl.unizeto.pki.des.ssp.trsmd.TRSMDBean"
initialContextFactory="org.jnp.interfaces.NamingContextFactory"
jndiProviderURL="192.168.129.202:1999"/>
</port>
</service>

<plnk:partnerLinkType name="TRSMService">
<plnk:role name="TRSMServiceProvider">
<plnk:portType name="tns:TRSMService"/>
</plnk:role>
</plnk:partnerLinkType>
</definitions>
and bpel source
<process name="TRSMBPEL" targetNamespace="http://xmlns.unizeto.pl/TRSMBPEL" xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/" xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/" xmlns:xp20="http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.Xpath20" xmlns:tns="http://xmlns.unizeto.pl/TRSMBPEL" xmlns:ns1="http://www.w3.org/2001/XMLSchema" xmlns:trsm="http://xmlns.unizeto.pl/TRSMBPEL" xmlns:ctask="http://services.oracle.com/bpel/task" xmlns:ldap="http://schemas.oracle.com/xpath/extension/ldap" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:taskMgr="http://services.oracle.com/bpel/task" xmlns:bpelx="http://schemas.oracle.com/bpel/extension" xmlns:ora="http://schemas.oracle.com/xpath/extension" xmlns:orcl="http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.ExtFunc">
<partnerLinks>
<partnerLink name="client" partnerLinkType="tns:TRSMBPEL" myRole="TRSMBPELProvider"/>
<partnerLink name="TRSMService" partnerRole="TRSMServiceProvider" partnerLinkType="tns:TRSMService"/>
<partnerLink myRole="TaskManagerRequester" name="userTask" partnerRole="TaskManager" partnerLinkType="taskMgr:TaskManager"/>
</partnerLinks>
<variables>
<variable name="inputVariable" messageType="tns:TRSMBPELRequestMessage"/>
<variable name="outputVariable" messageType="tns:TRSMBPELResponseMessage"/>
<variable name="SendPacketToTRSM_SendPacketToTRSM_InputVariable" messageType="tns:SendPacketToTRSMRequestMessage"/>
<variable name="SendPacketToTRSM_SendPacketToTRSM_OutputVariable" messageType="tns:SendPacketToTRSMResponseMessage"/>
<variable name="GetData_GetData_InputVariable" messageType="tns:GetDataRequestMessage"/>
<variable name="GetData_GetData_OutputVariable" messageType="tns:GetDataResponseMessage"/>
<variable name="UserTask2.0Var1" element="ctask:task"/>
<variable name="Invoke_1_Create_InputVariable" messageType="tns:CreateRequestMessage"/>
<variable name="Invoke_1_Create_OutputVariable" messageType="tns:CreateResponseMessage"/>
<variable name="removeTRSMD_Remove_InputVariable" messageType="tns:RemoveRequestMessage"/>
<variable name="removeTRSMD_Remove_OutputVariable" messageType="tns:RemoveResponseMessage"/>
</variables>
<sequence name="main">
<receive name="receiveInput" partnerLink="client" portType="tns:TRSMBPEL" operation="process" variable="inputVariable" createInstance="yes"/>
<scope name="Scope_1">
<variables>
<variable name="Invoke_3_Create_InputVariable" messageType="tns:CreateRequestMessage"/>
<variable name="Invoke_3_Create_OutputVariable" messageType="tns:CreateResponseMessage"/>
<variable name="Invoke_1_Remove_InputVariable" messageType="tns:RemoveRequestMessage"/>
</variables>
<sequence name="Sequence_1">
<assign name="Init">
<copy>
<from variable="inputVariable" part="payload" query="/tns:TRSMBPELProcessRequest/tns:sender"/>
<to variable="SendPacketToTRSM_SendPacketToTRSM_InputVariable" part="sender"/>
</copy>
<copy>
<from variable="inputVariable" part="payload" query="/tns:TRSMBPELProcessRequest/tns:buffer"/>
<to variable="SendPacketToTRSM_SendPacketToTRSM_InputVariable" part="bufferToTRSM"/>
</copy>
</assign>
<invoke name="create" partnerLink="TRSMService" portType="tns:TRSMService" operation="Create" inputVariable="Invoke_3_Create_InputVariable" outputVariable="Invoke_3_Create_OutputVariable"/>
<invoke name="SendPacketToTRSM" partnerLink="TRSMService" portType="tns:TRSMService" operation="SendPacketToTRSM" inputVariable="SendPacketToTRSM_SendPacketToTRSM_InputVariable" outputVariable="SendPacketToTRSM_SendPacketToTRSM_OutputVariable"/>
<invoke name="GetData" partnerLink="TRSMService" portType="tns:TRSMService" operation="GetData" inputVariable="GetData_GetData_InputVariable" outputVariable="GetData_GetData_OutputVariable"/>
<invoke name="Remove" partnerLink="TRSMService" portType="tns:TRSMService" operation="Remove" inputVariable="Invoke_1_Remove_InputVariable"/>
</sequence>
</scope>
<assign name="Result">
<copy>
<from variable="GetData_GetData_OutputVariable" part="result"/>
<to variable="outputVariable" part="payload" query="/tns:TRSMBPELProcessResponse/tns:data"/>
</copy>
</assign>
<reply name="replyOutput" partnerLink="client" portType="tns:TRSMBPEL" operation="process" variable="outputVariable"/>
</sequence>
</process>
Could anyone explain, is it possible to binding stateful bean to process?
Thanks
Norbert

Did some additional investigations and concluded"
The (embedded) OTC uses default the empty to obtain the reference to a Session Bean (EJB). In my case I was using the Remote Interface and my Context was empty { }:
Hashtable ht = ic.getEnvironment();
System.out.println(ht.toString());
When I supply the missing information, obtained via the Test Client that functions correctly, a new Bean instance was created for each Client. My getInitialContext() method looks like the example below.
public InitialContext getInitialContext() throws NamingException {
Properties p =new Properties();
p.setProperty( "java.naming.factory.initial", "com.evermind.server.rmi.RMIInitialContextFactory");
p.setProperty( "java.naming.provider.url", "ormi://localhost:23892/current-workspace-app" );
I tried the ApplicationInitialContextFactory and again the same Bean instance was shared among all Clients. I did not try ApplicationClientInitialContextFactory, but I expect that the Remote interface will be used!
Is it a Bug that ApplicationInitialContextFactory does not create a new instance for my Stateful Session Bean? I can use the Remote interface, but that would decrease the performance and it is less elegant...
Michael

Stateful session bean and faces

I have one stateful session bean(EJB) that manages business logic and conditional page flow. In the web part i have a bunch of JSP pages and each page has it's own JSF bean with data and "submit" methods. Each bean has to keep a reference to this stateful bean and it should be the same reference among all beans. Also i have to create and destroy this bean some way (I think i can use HttpSessionBindingListener).So, any suggestions how to do this? Also i'm searching for 'tips'n'tricks' or design pattern for JSF.
anton

why do you need to hold the same EJB reference in all your JSF beans?
something is wrong with your design, you should take a closer look to see why you need this. a stateless bean does not hold client specific state and there is no difference between stateless bean instances, so your JSF beans do not have to point to the same EJB reference.

Best way to remove Stateful session beans

Hi folks.
I'm running Weblogic 6.1. I'm trying to find the best way of removing
stateful session beans. I know to call EJBObject.remove() on the
client side, but this will not always happen if the client crashes or
times out. This is a java client application connection to weblogic,
no servlets are involved.
Is there a way to signal the appserver to remove all stateful session
beans associated with a user when the User logs out? I would rather
not remove them using a time out mechanism.
thanks.
rob.

But in the documentation and also based on my experience I noticed that the
timeout does not take effect till the max-beans-in-cache limit is reached.
How do you handle that?
"Thomas Christen" <[email protected]> wrote in message
news:3e35795d$[email protected]..
Hi,
Is there a way to signal the appserver to remove all stateful session
beans associated with a user when the User logs out? I would rather
not remove them using a time out mechanism.Had the same problem and solved it the following way :
- The client has thread polling its sessionbean at the server (every 30
Sec.)
- The session bean has a short timeout (2 Minutes)
If the client fails, the timeout will catch it otherwise the client will
gracefully call remove bevor exit.
Regards
Tomy

In-memory-replace for stateful session bean

When I add "<replication-type>InMemory</replication-type>" at the
          weblogic-ejb-jar.xml file,
          the client can't call this stateful session bean and happen exception.
          If I delete "<replication-type>InMemory</replication-type>" at the
          weblogic-ejb-jar.xml, the client can call this ejb.
          How does the In-memory-replac set?
          Is there any limitations about using the In-memory-replace?
          The weblogic-ejb-jar.xml and the exception are list.
          The weblogic-ejb-jar.xml:
          <?xml version="1.0"?>
          <!DOCTYPE weblogic-ejb-jar PUBLIC '-//BEA Systems, Inc.//DTD WebLogic 6.0.0
          EJB//EN' 'http://www.bea.com/servers/wls600/dtd/weblogic-ejb-jar.dtd'>
          <weblogic-ejb-jar>
          <weblogic-enterprise-bean>
          <ejb-name>test_stateful</ejb-name>
          <stateful-session-descriptor>
          <stateful-session-clustering>
          <home-is-clusterable>True</home-is-clusterable>
          <home-load-algorithm>round-robin</home-load-algorithm>
          <home-call-router-class-name>beanRouter</home-call-router-class-name>
          <replication-type>InMemory</replication-type>
          </stateful-session-clustering>
          </stateful-session-descriptor>
          <jndi-name>test_stateful</jndi-name>
          </weblogic-enterprise-bean>
          </weblogic-ejb-jar>
          The exception:
          java.rmi.RemoteException: EJB Exception: ; nested exception is:
          java.lang.ClassCastException:
          weblogic.rmi.internal.BasicRequestDispatcher
          java.lang.ClassCastException: weblogic.rmi.internal.BasicRequestDispatcher
          <<no stack trace available>>


This is a Work as designed in my opinion
with NRU ,the container work with an eager remove algorithm, this as stated need pressure at the cache to push the container to remove the beans from the cache ,hence there will no passivation unless the max-beans-in-cache is reached, hence you can try reducing the max-beans-in-cache and see how the caching behaves , if It does not help ,chnage the Algorithm of caching or open a Service Request for us , we can look at this closely
Regards
Anis

Local Stateful Session Bean State Failover Cluster

          Hi,
          How are you doing? I have poured through the previous postings and still am unclear
          on the following: If we have a stateful session bean that is local is the state
          replicated in a cluster if we are using in-memory replication?
          What controls when the state is replicated? Transactions?
          What happens if the methods are not transacted? Is the state replication at the
          method level?
          Thank you so much,
          -Bart Simpson


Hi Bart,
          I'm a bit unclear on it too. It's been asked before, but no definite answer
          has been provided.
          Peace,
          Cameron Purdy
          Tangosol, Inc.
          http://www.tangosol.com/coherence.jsp
          Tangosol Coherence: Clustered Replicated Cache for Weblogic
          "Bart Simpson" <[email protected]> wrote in message
          news:[email protected]..
          >
          > Hi,
          >
          > How are you doing? I have poured through the previous postings and still
          am unclear
          > on the following: If we have a stateful session bean that is local is the
          state
          > replicated in a cluster if we are using in-memory replication?
          >
          > What controls when the state is replicated? Transactions?
          >
          > What happens if the methods are not transacted? Is the state replication
          at the
          > method level?
          >
          > Thank you so much,
          > -Bart Simpson

HttpSession vs. Stateful Session Bean ---- when State Session is large

I hope most of the people come across with this issue where to put the state
for the internet/intranet based applications when they are using
servlet/jsps calling session beans. Weblogic 4.5.1 does support httpsession
in-memory replication for the servlets but the stateful session beans are
not replicated in clustered environment. Plus with stateful bean u get
activation/passivation overhead too. So one tempts to use stateless session
beans and store state in httpsession?
Then what is the upper limit for the session state one can put in
HttpSession with the weblogic? Is there any way to configure it?
One way to overcome the httpsession size limitation is to use database for
storing state and just store some unique Ids for the session info in
httpSession. But then there will be overhead for database connection?(jdbc
connection pool can provide some help here). So what is the recommended way
for doing this provided few thousand concurrent clients with session size
say exceeding 4kb per client?
Thanks
Usmani

There are no special setting in sun-ejb-jar.xml regarding cache settings. The default settings from server.xml are used:
    <jdbc-connection-pool steady-pool-size="8" max-pool-size="32" max-wait-time-in-millis="60000" pool-resize-quantity="2" idle-timeout-in-seconds="300" is-isolation-level-guaranteed="false" is-connection-validation-required="false" connection-validation-method="auto-commit" fail-all-connections="false" datasource-classname="oracle.jdbc.pool.OracleDataSource" name="ebs">
      <property value="jdbc:oracle:thin:@myebsdbsserver:1521:ebsdevdb" name="url"/>
      <property value="ebs" name="user"/>
      <property value="ebs" name="password"/>
    </jdbc-connection-pool>
<ejb-container steady-pool-size="32" pool-resize-quantity="16" max-pool-size="64" cache-resize-quantity="32" max-cache-size="512" pool-idle-timeout-in-seconds="600" cache-idle-timeout-in-seconds="600" removal-timeout-in-seconds="5400" victim-selection-policy="nru" commit-option="B" monitoring-enabled="true">
     </ejb-container>The Session Bean uses Container Managed Transaction. Is it possible in this case, that the bean isn't 'idle enough' in order to set into passivated?

Cannot remove stateful session bean when transaction timed out

The transaction timeout is set to 5 minutes. After several operations on the transactional
stateful session bean(implements SessionSynchronization), the transaction timed out
after 5 minutes and I got the IllegalStateException when calling another business
method. After the transaction rolled back, weblogic.ejb20.locks.LockTimedOutException
was thrown when attempting to remove the bean. It seems the lock on the bean was
not released even though the transaction had been rolled back. Does anyone know how
to remove the bean in this kind of situation?
Here is the stacktrace:
####<Jun 11, 2002 2:39:35 PM PDT> <Notice> <EJB> <app1x.zaplet.cc> <server25044server>
<ExecuteThread: '11' for queue: 'default'> <> <23168:7b09681c532dc7e3> <010015> <Error
marking transaction for rollback: java.lang.IllegalStateException: Cannot mark the
transaction for rollback. xid=23168:7b09681c532dc7e3, status=Rolled back. [Reason=weblogic.transaction.internal.TimedOutException:
Transaction timed out after 299 seconds
Xid=23168:7b09681c532dc7e3(3203140),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds
since begin=299,seconds left=60,activeThread=Thread[ExecuteThread: '11' for queue:
'default',5,Thread Group for Queue: 'default'],ServerResourceInfo[weblogic.jdbc.jts.Connection]=(state=ended,assigned=none),SCInfo[server25044+server25044server]=(state=active),properties=({weblogic.jdbc=t3://10.0.100.93:7001}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=server25044server+10.0.100.93:7001+server25044+,
Resources={})],CoordinatorURL=server25044server+10.0.100.93:7001+server25044+)]>
java.lang.IllegalStateException: Cannot mark the transaction for rollback. xid=23168:7b09681c532dc7e3,
status=Rolled back. [Reason=weblogic.transaction.internal.TimedOutException: Transaction
timed out after 299 seconds
Xid=23168:7b09681c532dc7e3(3203140),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds
since begin=299,seconds left=60,activeThread=Thread[ExecuteThread: '11' for queue:
'default',5,Thread Group for Queue: 'default'],ServerResourceInfo[weblogic.jdbc.jts.Connection]=(state=ended,assigned=none),SCInfo[server25044+server25044server]=(state=active),properties=({weblogic.jdbc=t3://10.0.100.93:7001}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=server25044server+10.0.100.93:7001+server25044+,
Resources={})],CoordinatorURL=server25044server+10.0.100.93:7001+server25044+)]
     at weblogic.transaction.internal.TransactionImpl.throwIllegalStateException(TransactionImpl.java:1486)
     at weblogic.transaction.internal.TransactionImpl.setRollbackOnly(TransactionImpl.java:466)
     at weblogic.ejb20.manager.BaseEJBManager.handleSystemException(BaseEJBManager.java:255)
     at weblogic.ejb20.manager.BaseEJBManager.setupTxListener(BaseEJBManager.java:215)
     at weblogic.ejb20.manager.StatefulSessionManager.preInvoke(StatefulSessionManager.java:371)
     at weblogic.ejb20.internal.BaseEJBObject.preInvoke(BaseEJBObject.java:117)
     at weblogic.ejb20.internal.StatefulEJBObject.preInvoke(StatefulEJBObject.java:169)
     at mypackage.MyBean_wbr3eg_EOImpl.addRecipients(MyBean_wbr3eg_EOImpl.java:450)
####<Jun 11, 2002 2:39:37 PM PDT> <Info> <EJB> <app1x.zaplet.cc> <server25044server>
<ExecuteThread: '11' for queue: 'default'> <> <> <010049> <EJB Exception in method:
remove: weblogic.ejb20.locks.LockTimedOutException: The lock request from EJB:AppmailBean
with primary key:21,775,960,933,010,237 timed-out after waiting 0 ms. The transaction
or thread requesting the lock was:Thread[ExecuteThread: '11' for queue: 'default',5,Thread
Group for Queue: 'default'].>
weblogic.ejb20.locks.LockTimedOutException: The lock request from EJB:AppmailBean
with primary key:21,775,960,933,010,237 timed-out after waiting 0 ms. The transaction
or thread requesting the lock was:Thread[ExecuteThread: '11' for queue: 'default',5,Thread
Group for Queue: 'default'].
     at weblogic.ejb20.locks.ExclusiveLockManager$LockBucket.lock(ExclusiveLockManager.java:448)
     at weblogic.ejb20.locks.ExclusiveLockManager.lock(ExclusiveLockManager.java:258)
     at weblogic.ejb20.manager.StatefulSessionManager.acquireLock(StatefulSessionManager.java:226)
     at weblogic.ejb20.manager.StatefulSessionManager.acquireLock(StatefulSessionManager.java:216)
     at weblogic.ejb20.manager.StatefulSessionManager.preInvoke(StatefulSessionManager.java:310)
     at weblogic.ejb20.manager.StatefulSessionManager.remove(StatefulSessionManager.java:754)
     at weblogic.ejb20.internal.StatefulEJBObject.remove(StatefulEJBObject.java:86)
     at mypackage.MyBean_wbr3eg_EOImpl.remove(MyBean_wbr3eg_EOImpl.java:7308)

If a stateful session throws a RuntimeException (your rollback) the container destroys the instance of the bean and all
associated state information is lost, as required by the EJB specification.
If you want to maintain client state it is generally best to use HttpSession objects (if you have a web application)
for short-lived, client-specific data and JPA entities or other database backed storage for long-lived data.

Stateful Session Bean with BMT: JDBCpmf or EEpmf?

Quote:
For the record: when using BMT as David described, you should use a JDBCPersistenceManagerFactory
instead of an EEPersistenceManagerFactory. EEPersistenceManagerFactory is only appropriate when
transaction synchronization is desired.
-Patrick
Hi Patrick,
I wanted to follow up on this. In the case of Kodo, the JDBCpmf does not turn on the
UserTransaction in a managed environment, while the EEpmf does. My question: isn't is necessary to
turn on the UserTransaction in a stateful session bean with BMT? If this doesn't happen, isn't
there a danger, if the bean allows transactions to span business method invocations, that the
container will passivate the bean while a transaction is active? Since the PM can't be saved during
passivation, the tx would be interrupted by passivation -- something that would not happen if the
container were aware that a tx was active.
David Ezzio

David,
My interpretation of your initial post was that you were using fully
unmanaged transactions in your bean. That is, that you were not using the
UserTransaction, but were just using the javax.jdo.Transaction for
transactional data store access.
In the situation I just described, using the EEPMF would result in changes
to the UserTransaction. If your goal was to manage the UserTransaction in
the bean, then yes, you'd still want to use the EEPMF.
-Patrick
On 7/25/02 7:17 PM, "David Ezzio" <[email protected]> wrote:
Quote:
For the record: when using BMT as David described, you should use a
JDBCPersistenceManagerFactory
instead of an EEPersistenceManagerFactory. EEPersistenceManagerFactory is only
appropriate when
transaction synchronization is desired.
-Patrick
Hi Patrick,
I wanted to follow up on this. In the case of Kodo, the JDBCpmf does not turn
on the
UserTransaction in a managed environment, while the EEpmf does. My question:
isn't is necessary to
turn on the UserTransaction in a stateful session bean with BMT? If this
doesn't happen, isn't
there a danger, if the bean allows transactions to span business method
invocations, that the
container will passivate the bean while a transaction is active? Since the PM
can't be saved during
passivation, the tx would be interrupted by passivation -- something that
would not happen if the
container were aware that a tx was active.
David Ezzio--
Patrick Linskey [email protected]
SolarMetric Inc. http://www.solarmetric.com

Caching data in stateful sesion bean

Similar Messages

Maybe you are looking for