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'>
<!-- Generated XML! -->
<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
Similar Messages
-
Stateful session bean does not rollback TX
I am unable to figure out why my stateful session bean is unable to rollback transactions
when I throw an EJBException. My stateful session bean has an ejbCreate method
which calls 2 other creates on 2 entity beans. If one of the entity beans successfully
creates and the other throws a CreateException, i catch it and throw an EJBException.
The created entity bean should roll back but it doesnt. Can it be because I
am calling the beans from within the session bean's ejbCreate method?
All beans are set to transaction REQUIRED, using bea's TXDatasource, and running
WL 6.1 sp2 on windows 2000.
help!Session bean create methods run in an unspecified transaction. So your two calls to the
entity bean are running in separate txs.
-- Rob
Rob Pak wrote:
I am unable to figure out why my stateful session bean is unable to rollback transactions
when I throw an EJBException. My stateful session bean has an ejbCreate method
which calls 2 other creates on 2 entity beans. If one of the entity beans successfully
creates and the other throws a CreateException, i catch it and throw an EJBException.
The created entity bean should roll back but it doesnt. Can it be because I
am calling the beans from within the session bean's ejbCreate method?
All beans are set to transaction REQUIRED, using bea's TXDatasource, and running
WL 6.1 sp2 on windows 2000.
help!--
AVAILABLE NOW!: Building J2EE Applications & BEA WebLogic Server
by Michael Girdley, Rob Woollen, and Sandra Emerson
http://learnWebLogic.com
[att1.html] -
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
UsmaniThere 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? -
How do i get back my stateful session bean after it has been passivated
hi ,
How do i get back my stateful session bean after it has been passivated by container.
i'm confused that is it possible or not .......give me answer
i've one stateful sessionbean which i'm accessing throgh my normal java client . now what i'm doing is when i first time call a method it is running ......then i'm shutting down the server jboss .......it is calling my ejbPassivate() method ... at this particular time client program doesn't do anything.....
now after i restart my server i'm again calling back that business method with that last object reference.......it gives me the exception given below.....
java.rmi.NoSuchObjectException: no such object in table
java.rmi.NoSuchObjectException: no such object in table
at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(Unknown Source)
at sun.rmi.transport.StreamRemoteCall.executeCall(Unknown Source)
at sun.rmi.server.UnicastRef.invoke(Unknown Source)
at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(Unknown Source)
at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:118)
at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:227)
at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:167)
at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:46)
at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:55)
at org.jboss.proxy.ejb.StatefulSessionInterceptor.invoke(StatefulSessionInterceptor.java:106)
at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:86)
at $Proxy1.makeNewAcc(Unknown Source)
at client.GanJavaClient.main(GanJavaClient.java:46)so pls tell me that is it possible to get back that session besn or notStateful session beans are not persisted across restart of the EJB server instance(s) hosting them. You can't treat a Session bean as one would an entity bean.
Chuck -
Max number of instances for stateful session beans
Hi,
I am using OC4J 9.0.3 which is embedded in JDeveloper. I would like to set the maximum number of instances for stateful session beans. I know that the session-deployment section of the orion-ejb-jar.xml file has an attribute called max-instances, but it only works for stateless session beans. (at least it says so in the documentation and it did not work with my stateful session bean)
Anyone knows how to do it?
Thanks,
Leonardo PenhaLeonardo -- Stateful session beans do not come from a pool but are assigned 1 bean to 1 user. When the EJBs life ends the bean goes away. If what you are asking about is passivation configuraiton then that is different. We currently do not support passivation based on some count of SFSBs that exists inside the container but we will provide that capability in the next release of OC4J. (Note: When passivation occurs is mostly up to the vendors and it is not required by the J2EE 1.3 specification based on performance metrics. What is required is that when a SFSB is passivated it is done correctly and we do that.)
Thanks -- Jeff -
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
>>
>
>
-
Stateful session bean destroying instance variables?
I'm trying to use a stateful session bean as some kind of login controller and to maintain the login id and access level across JSPs and HTMLs so that once logged in, all the JSPs can obtain the login name of the current user (String) and his access level (int).
I use the login.jsp to login and it successfully reports logging in with the correct access level retrieved from database. However, if I go to another JSP (testlogin.jsp), these 2 EJB instance variables are always destroyed and set to null and 0 when I access them again.
What am I missing that my stateful session bean is not saving these instance variables? Do I need to put them in some serializable value objects (create a help VO class?)
I suspected that on different JSP, I call the MemberControllerHome.create() method, it creates a new instance or something but if I don't use the create method how do I get a handle to MemberController at all?
MemberControllerBean.java
public class MemberControllerBean implements SessionBean {
//initialize in ejbCreate.
private MemberHome memberHome;
SessionContext context;
//Member currentLogin;
//Current Login
private String loginID;
private int accessLevel;
// Constructor
public MemberControllerBean() {}
...some code in between...
public void login(String id, String password){
try{
Member member = null;
member = memberHome.findByPrimaryKey(id);
if(member.getMPassword().equals(password)){
this.loginID = member.getMID();
this.accessLevel = member.getMAccessLevel();
else{
throw new EJBException("Login failed. Invalid member ID and/or password.");
} catch (FinderException ex) {
throw new EJBException("Login failed. Invalid member ID and/or password.");
public void logout(){
this.loginID = null;
this.accessLevel = 4;
public String getLoginID(){
return this.loginID;
public int getLoginAccessLevel(){
return this.accessLevel;
login.jsp
String mID = request.getParameter("mID");
String mPassword = request.getParameter("mPassword");
out.println("20:" + mID + ":" + mPassword);
if(mID != null && mPassword != null){
out.println("22:" + mID + ":" + mPassword);
try{
InitialContext ic = new InitialContext();
MemberControllerHome home = (MemberControllerHome) ic.lookup("java:comp/env/ejb/MemberController");
MemberController mc = home.create();
out.println("26:Logging in as " + mID + " with " + mPassword);
mc.login(mID, mPassword);
out.println("28:" + mc.getLoginID() + "logged in successfully at level " +
mc.getLoginAccessLevel() + ".");
} catch (NamingException ex) {
out.println("java:comp/env/ejb/MemberController not found.");
} catch (EJBException ex) {
out.println(ex.getMessage());
} catch (Exception ex) {
out.println(ex.getMessage());
testlogin.jsp
<%
try{
InitialContext ic = new InitialContext();
MemberControllerHome home = (MemberControllerHome) ic.lookup("java:comp/env/ejb/MemberController");
MemberController mc = home.create();
out.println("You are logged in as <b>" + mc.getLoginID() +
"</b> at level <b>" + mc.getLoginAccessLevel() + "</b>.");
} catch (NamingException ex) {
out.println("java:comp/env/ejb/MemberController not found.");
} catch (EJBException ex) {
out.println(ex.getMessage());
} catch (Exception ex) {
out.println(ex.getMessage());
%>The key to the problem is that in testlogin.jsp a new stateful session bean is created. The new bean instance of course doesn't know the log-in information you stored in the old session bean. That is why the method returns null and 0 when called.
There are couple of ways to solve the issue. The easiest solution is to store the bean instance created in Login.jsp in the jsp's implicit HttpSession object. Because login.jsp and testlogin.jsp share the same session, the bean instance can be easily stored and retrieved.
Here is the code you need to have:
1. in login.jsp
session.setAttribute("MemberControllerBeanInstance", mc);
2. in testlogin.jsp
MemberController mc =
(MemberController) session.getAttribute("MemberControllerBeanInstance");
Hope it helps. -
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 -
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
-
Passivation of Connection Object in Stateful Session Bean
Hi all,
I am developing a Stateful session bean that has a Connection object as its instance variable. And this bean starts transaction that spans across multiple method calls and finally either commit or rollback.
BeanClass
UserTransaction utx;
Connection conn;
ejbCreate()
allocateconnection();
ejbRemove()
closeconnection();
ejbActivate()
allocateconnection();
ejbpassivate()
closeconnection();
StartTransaction()
utx = getusertransaction();
utx.begin();
Method1()
do something with database
Method2()
do something with database
CommitTransaction()
utx.commit();
For example, the typical usage of this bean would be:
bean.StartTransaction();
bean.Method1();
bean.Method2();
bean.CommitTransaction();
Here are my two questions:
1. General Question: In order for a Connection object to join a Transaction, Do I have to create the connection after the transaction has started?
2. If the answer to the above question is yes, then: I understand that when this bean get passivated, the UserTransaction instance object would be passivated. And since the connection object can't not be passivated, I have to recreate the connection object in ejbactivate() method, would newly created connection participate in the same Transaction that was being passivated and now activated?>
Hi all,
I am developing a Stateful session bean that has a
Connection object as its instance variable. And this
bean starts transaction that spans across multiple
method calls and finally either commit or rollback.
BeanClass
UserTransaction utx;
Connection conn;
ejbCreate()
allocateconnection();
ejbRemove()
closeconnection();
ejbActivate()
allocateconnection();
ejbpassivate()
closeconnection();
StartTransaction()
utx = getusertransaction();
utx.begin();
Method1()
do something with database
Method2()
do something with database
CommitTransaction()
utx.commit();
For example, the typical usage of this bean would be:
bean.StartTransaction();
bean.Method1();
bean.Method2();
bean.CommitTransaction();
Here are my two questions:
1. General Question: In order for a Connection object
to join a Transaction, Do I have to create the
connection after the transaction has started?Strictly NO. In fact, the connection is obtained first and then can a transaction begin.
2. If the answer to the above question is yes, then: I
understand that when this bean get passivated, the
UserTransaction instance object would be passivated.
And since the connection object can't not be
passivated, I have to recreate the connection object
in ejbactivate() method, would newly created
connection participate in the same Transaction that
was being passivated and now activated?
The answer to first question being NO, your argument for question 2 does not hold true. According to the EJB specification, a stateful session bean can only be passivated between the transaction and not within a transaction. Your implementation for the stateful EJB is good to work. -
Stop passivation in stateful session bean
hi
How to stop the passivation in stateful session bean
Regards
Gajendran.G>
Hi all,
I am developing a Stateful session bean that has a
Connection object as its instance variable. And this
bean starts transaction that spans across multiple
method calls and finally either commit or rollback.
BeanClass
UserTransaction utx;
Connection conn;
ejbCreate()
allocateconnection();
ejbRemove()
closeconnection();
ejbActivate()
allocateconnection();
ejbpassivate()
closeconnection();
StartTransaction()
utx = getusertransaction();
utx.begin();
Method1()
do something with database
Method2()
do something with database
CommitTransaction()
utx.commit();
For example, the typical usage of this bean would be:
bean.StartTransaction();
bean.Method1();
bean.Method2();
bean.CommitTransaction();
Here are my two questions:
1. General Question: In order for a Connection object
to join a Transaction, Do I have to create the
connection after the transaction has started?Strictly NO. In fact, the connection is obtained first and then can a transaction begin.
2. If the answer to the above question is yes, then: I
understand that when this bean get passivated, the
UserTransaction instance object would be passivated.
And since the connection object can't not be
passivated, I have to recreate the connection object
in ejbactivate() method, would newly created
connection participate in the same Transaction that
was being passivated and now activated?
The answer to first question being NO, your argument for question 2 does not hold true. According to the EJB specification, a stateful session bean can only be passivated between the transaction and not within a transaction. Your implementation for the stateful EJB is good to work. -
EJB 2.0 STATEFUL SESSION BEANS -- ejbPassivate or ejbActivate is not called
Hi,
am using Oracle Jdevloper 9i. When i use Stateful Session beans the ejbPassivate or ejbActivated methods are not being called. What is the reason?Hi Arun,
The decision of when to passivate a stateful session bean is up to a particular vendor's implementation. Typically each vendor will have some configuration that controls this decision, but it's certainly common for passivation to not take place for a given workload. Your best bet is to look at the Oracle documentation to see how the container makes its passivation decision.
--ken -
Error While passivating Stateful session bean
I also have same problem when WL passivating. However, the exception throwing from
WL saying the "Ignoring exception raised while passivating".
My question is will that exception lead to failure of passivating and evenually
lead to memory leakage? I just thought that the memory is still in cache either
removed or passivated, as a result more and more memory will be used up as more
failure occurs.
Frank
Rob Woollen <[email protected]> wrote:
It looks like you have a reference to a DB Connection as a member
variable. This reference should be transient. You can re-acquire it
in
ejbActivate.
-- Rob
Hemant Arora wrote:
Hi
Can anybody please clarify the error that I'm getting while runningthe
stateful session bean with weblogic
I have instantiated 20 stateful session beans all using the DB connection
but if the connection is unaailable I'm making the beans to wait.
I'm not removeing the beans and again making the instance of 20 another
beans
The max beans in cache is 25.
Thanks
Hemant
This is the output at the console of the weblogic
ejbPassivate()
Tue Jul 17 20:58:00 GMT+05:30 2001:<I> <EJB JAR deployment
d:/weblogic/myserver/romanCount.jar> Ignoring exception raised while
passivating:
java.io.NotSerializableException:
weblogic.jdbc20.rmi.internal.ConnectionImpl
at
java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1148)
at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366)
at
java.io.ObjectOutputStream.outputClassFields(ObjectOutputStream.java:1841)
at
java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:480)
at
java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1214)
at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366)
at
java.io.ObjectOutputStream.outputClassFields(ObjectOutputStream.java:1841)
at
java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:480)
Coming Soon: Building J2EE Applications & BEA WebLogic Server
by Michael Girdley, Rob Woollen, and Sandra Emerson
http://learnweblogic.com -
Stateful session Bean in Model not working
I made a sample application very very simple, and the weblogic server cant find the @stateful annotation on the class. is it there another possibility? here i post the error i get:
[Running application MyTest1 on Server Instance IntegratedWebLogicServer...]
[09:48:51 PM] ---- Deployment started. ----
[09:48:51 PM] Target platform is (Weblogic 10.3).
[09:48:52 PM] Retrieving existing application information
[09:48:52 PM] Running dependency analysis...
[09:48:52 PM] Deploying 3 profiles...
[09:48:53 PM] Wrote Web Application Module to /home/issanllo/.jdeveloper/system11.1.1.2.36.55.36/o.j2ee/drs/MyTest1/ViewWebApp.war
[09:48:53 PM] Wrote EJB Module to /home/issanllo/.jdeveloper/system11.1.1.2.36.55.36/o.j2ee/drs/MyTest1/ModelEJB.jar
[09:48:53 PM] Wrote Enterprise Application Module to /home/issanllo/.jdeveloper/system11.1.1.2.36.55.36/o.j2ee/drs/MyTest1
[09:48:53 PM] Deploying Application...
<03-jun-2010 21H48' CEST> <Error> <Deployer> <BEA-149265> <Failure occurred in the execution of deployment request with ID '1275594533727' for task '2'. Error is: 'weblogic.application.ModuleException: Exception preparing module: EJBModule(ModelEJB.jar)
[EJB:011023]An error occurred while reading the deployment descriptor. The error was:
No EJBs found in the ejb-jar file {0}. Please ensure the ejb-jar contains EJB declarations via an ejb-jar.xml deployment descriptor or at least one class annotated with the @Stateless, @Stateful or @MessageDriven EJB annotation..'
weblogic.application.ModuleException: Exception preparing module: EJBModule(ModelEJB.jar)
[EJB:011023]An error occurred while reading the deployment descriptor. The error was:
No EJBs found in the ejb-jar file {0}. Please ensure the ejb-jar contains EJB declarations via an ejb-jar.xml deployment descriptor or at least one class annotated with the @Stateless, @Stateful or @MessageDriven EJB annotation..
at weblogic.ejb.container.deployer.EJBModule.prepare(EJBModule.java:454)
at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:199)
at weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(DeploymentCallbackFlow.java:391)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:83)
at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:59)
Truncated. see log file for complete stacktrace
Caused By: java.io.IOException: No EJBs found in the ejb-jar file {0}. Please ensure the ejb-jar contains EJB declarations via an ejb-jar.xml deployment descriptor or at least one class annotated with the @Stateless, @Stateful or @MessageDriven EJB annotation.
at weblogic.ejb.container.dd.xml.EjbDescriptorReaderImpl.createReadOnlyDescriptorFromJarFile(EjbDescriptorReaderImpl.java:219)
at weblogic.ejb.spi.EjbDescriptorFactory.createReadOnlyDescriptorFromJarFile(EjbDescriptorFactory.java:93)
at weblogic.ejb.container.deployer.EJBModule.loadEJBDescriptor(EJBModule.java:1210)
at weblogic.ejb.container.deployer.EJBModule.prepare(EJBModule.java:382)
at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:199)
Truncated. see log file for complete stacktrace
>
<03-jun-2010 21H48' CEST> <Warning> <Deployer> <BEA-149004> <Failures were detected while initiating deploy task for application 'MyTest1'.>
<03-jun-2010 21H48' CEST> <Warning> <Deployer> <BEA-149078> <Stack trace for message 149004
weblogic.application.ModuleException: Exception preparing module: EJBModule(ModelEJB.jar)
[EJB:011023]An error occurred while reading the deployment descriptor. The error was:
No EJBs found in the ejb-jar file {0}. Please ensure the ejb-jar contains EJB declarations via an ejb-jar.xml deployment descriptor or at least one class annotated with the @Stateless, @Stateful or @MessageDriven EJB annotation..
at weblogic.ejb.container.deployer.EJBModule.prepare(EJBModule.java:454)
at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:199)
at weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(DeploymentCallbackFlow.java:391)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:83)
at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:59)
Truncated. see log file for complete stacktrace
Caused By: java.io.IOException: No EJBs found in the ejb-jar file {0}. Please ensure the ejb-jar contains EJB declarations via an ejb-jar.xml deployment descriptor or at least one class annotated with the @Stateless, @Stateful or @MessageDriven EJB annotation.
at weblogic.ejb.container.dd.xml.EjbDescriptorReaderImpl.createReadOnlyDescriptorFromJarFile(EjbDescriptorReaderImpl.java:219)
at weblogic.ejb.spi.EjbDescriptorFactory.createReadOnlyDescriptorFromJarFile(EjbDescriptorFactory.java:93)
at weblogic.ejb.container.deployer.EJBModule.loadEJBDescriptor(EJBModule.java:1210)
at weblogic.ejb.container.deployer.EJBModule.prepare(EJBModule.java:382)
at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:199)
Truncated. see log file for complete stacktrace
>
#### Cannot run application MyTest1 due to error deploying to IntegratedWebLogicServer.
[09:48:54 PM] #### Deployment incomplete. ####
[09:48:54 PM] Remote deployment failed (oracle.jdevimpl.deploy.common.Jsr88RemoteDeployer)
[Application MyTest1 stopped and undeployed from Server Instance IntegratedWebLogicServer]
and the very simple class with a Local and Remote interfaces at Model project in jDeveloper 11g (11.1.1.3)
package test.core;
import java.util.ArrayList;
import java.util.List;
import javax.ejb.Local;
import javax.ejb.Remote;
import javax.ejb.Stateful;
@Stateful(name = "ControlSessionBean", mappedName = "MyTest1-Model-ControlSessionBean")
public class ControlSessionBean implements ControlSessionRemote,
ControlSessionLocal
private String username;
private String password;
public ControlSessionBean()
public List simple()
List <String> s = new ArrayList();
s.add(username);
s.add(password);
return s;
any suggestions why it is not working??
sincerely
Israel S Llorensnot working... i tried to make the stateful session bean Control.. and is still not working the error i get now is this one:
<04-jun-2010 16H29' CEST> <Error> <Deployer> <BEA-149265> <Failure occurred in the execution of deployment request with ID '1275661769594' for task '9'. Error is: 'weblogic.application.ModuleException: Could not setup environment'
weblogic.application.ModuleException: Could not setup environment
at weblogic.servlet.internal.WebAppModule.activateContexts(WebAppModule.java:1499)
at weblogic.servlet.internal.WebAppModule.activate(WebAppModule.java:442)
at weblogic.application.internal.flow.ModuleStateDriver$2.next(ModuleStateDriver.java:375)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:41)
at weblogic.application.internal.flow.ModuleStateDriver.activate(ModuleStateDriver.java:95)
Truncated. see log file for complete stacktrace
Caused By: weblogic.deployment.EnvironmentException: [J2EE:160200]Error resolving ejb-ref 'gecu.view.LoginBean/controlBean' from module 'GeCU_Web_view_root' of application 'GeCU_Web'. The ejb-ref does not have an ejb-link and the JNDI name of the target bean has not been specified. Attempts to automatically link the ejb-ref to its target bean failed because no EJBs in the application were found to implement the 'gecu.model.ControlSession' interface. Please link or map this ejb-ref to its target EJB and ensure the interfaces declared in the ejb-ref are correct.
at weblogic.deployment.BaseEnvironmentBuilder.autowireEJBRef(BaseEnvironmentBuilder.java:427)
at weblogic.deployment.EnvironmentBuilder.addEJBReferences(EnvironmentBuilder.java:502)
at weblogic.servlet.internal.CompEnv.activate(CompEnv.java:157)
at weblogic.servlet.internal.WebAppServletContext.activate(WebAppServletContext.java:3117)
at weblogic.servlet.internal.WebAppModule.activateContexts(WebAppModule.java:1497)
Truncated. see log file for complete stacktrace
>
<04-jun-2010 16H29' CEST> <Error> <Deployer> <BEA-149202> <Encountered an exception while attempting to commit the 9 task for the application 'GeCU_Web'.>
<04-jun-2010 16H29' CEST> <Warning> <Deployer> <BEA-149004> <Failures were detected while initiating deploy task for application 'GeCU_Web'.>
<04-jun-2010 16H29' CEST> <Warning> <Deployer> <BEA-149078> <Stack trace for message 149004
weblogic.application.ModuleException: Could not setup environment
at weblogic.servlet.internal.WebAppModule.activateContexts(WebAppModule.java:1499)
at weblogic.servlet.internal.WebAppModule.activate(WebAppModule.java:442)
at weblogic.application.internal.flow.ModuleStateDriver$2.next(ModuleStateDriver.java:375)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:41)
at weblogic.application.internal.flow.ModuleStateDriver.activate(ModuleStateDriver.java:95)
Truncated. see log file for complete stacktrace
Caused By: weblogic.deployment.EnvironmentException: [J2EE:160200]Error resolving ejb-ref 'gecu.view.LoginBean/controlBean' from module 'GeCU_Web_view_root' of application 'GeCU_Web'. The ejb-ref does not have an ejb-link and the JNDI name of the target bean has not been specified. Attempts to automatically link the ejb-ref to its target bean failed because no EJBs in the application were found to implement the 'gecu.model.ControlSession' interface. Please link or map this ejb-ref to its target EJB and ensure the interfaces declared in the ejb-ref are correct.
at weblogic.deployment.BaseEnvironmentBuilder.autowireEJBRef(BaseEnvironmentBuilder.java:427)
at weblogic.deployment.EnvironmentBuilder.addEJBReferences(EnvironmentBuilder.java:502)
at weblogic.servlet.internal.CompEnv.activate(CompEnv.java:157)
at weblogic.servlet.internal.WebAppServletContext.activate(WebAppServletContext.java:3117)
at weblogic.servlet.internal.WebAppModule.activateContexts(WebAppModule.java:1497)
Truncated. see log file for complete stacktrace
>
[04:29:35 PM] #### Deployment incomplete. ####
[04:29:35 PM] Remote deployment failed -
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.
Maybe you are looking for
-
I just installed XE on WXP and although the web interface works fine I can't use SQL+ Below is some information. This is very frustrating. I am an application developer; I switched from the full 10g to XE in the hope that I would no longer be wasting
-
0 down vote favorite I would like to ask the following question. I am using mac os x 10.9 maverics me quicktime player version 10.3. Can I trim a video recording without having to press the pause or save it as a file? Or can I add a new recording
-
Hello, I have a problem with WorkFlow Notification. When a send a workflow test notification. I reveive the mail, in my inbox. I use Webaccess. The notification server works. But in the body of the mail, i don't have the Acknowledge button, I have on
-
I have used the HELP section, and tried my best to find a way to save specific e-mails. There is no BOX marked SAVE, and the help section gives no pertinent information on saving e-mails. This function is extremely important for my work functions. Yo
-
Hi all I have a problem downloading the long text from the BW report to Excel when I export it. I want the entire string(around 1000 chars) to be displayed in a single cell in excell sheet. How can I do it? regards Paul