Stateful Session Bean Question

I have a stateful session bean being invoked by my web tier on several request/response transactions. What would be the best way to locate the same session bean ? Would that be the create method in the Home i/f or would i need to supply a finder method for locating an existing bean?

Hi,
Store HomeObject or EJB Object in the Session in the WebTier.
Anil

Similar Messages

EJB 3.0 Stateful session bean shared between Servlet's

Hello
I have a bit of a noob question regarding Stateful sessions beans.
I am wanting to know if there is a way that I can share an instance of a session bean between multiple HttpServlet instances?
I am sending XML messages from a mobile J2ME application, there will be several http POST's made from the mobile client to the server. I would like these multiple POST's to be passed from the handling servlet instance to the same uniquely identified single stateful session bean instance (i can then @Remove the stateful bean when I have finished my several requests).
I would greatly appreciate any tips anyone could give me.

If not, your only option is to maintain the
association yourself by creating a unique id for
each
conversation and storing that id along with the SFSB
reference in the ServletContext. Then you'll
need to pass the id in along with each invocation to
retrieve the appropriate SFSB reference.Thanks for your reply.
Will I always be presented with the same ServletContext instance? Even if the time between requests might be many minutes? Where can I learn more about how to use the ServletContext?
Thanks!

Creating multiple stateful session beans from a java client. (EJB 3.0)

I'm having difficulties with the following:
To access the ShoppingCartBean, I have to put the following annotation in my standalone java client:
@EJB
private static ShoppingCartRemote shoppingCartBean;
The static must be there, thus only one ShoppingCartBean will exist within my java client. But as the ShoppingCartBean is a stateful session bean, I want to be able to get different beans of the same type.
What is the correct way to do this in EJB 3.0?

Great question. Because Home interfaces have been removed for the EJB 3.0 simplified
API, stateful session bean creation happens as a side-effect of injection. However, the
same is true of EJB 3.0 business interface lookups. The easiest way to create additional
stateful session beans is to lookup the same dependency that was declared via your
@EJB annotation.
E.g.,
// Assuming the declaring class is pkg1.ShoppingCartClient.java
InitialContext ic = new InitialContext();
ShoppingCartRemote scr1 = (ShoppingCartRemote)
ic.lookup("java:comp/env/pkg1.ShoppingCartClient/shoppingCartBean");
Note that the name relative to java:comp/env is the default associated with your
@EJB annotation since the name() attribute wasn't used. Alternatively, you
could have used :
@EJB(name="scb") private static ShoppingCartRemote shoppingCartBean;
InitialContext ic = new InitialContext();
ShoppingCartRemote scr1 = (ShoppingCartRemote) ic.lookup("java:comp/env/scb");
Yet another alternative is to declare the @EJB at the class-level. This just defines
the dependency without any injection, which is fine if you want to create a bunch of
them via lookup anyway.
@EJB(name="scb", beanInterface=ShoppingCartRemote.class)
public class .... {

Context.lookup in a Servlet always returns the same Stateful Session Bean

Hi,
I am working on an application in which a Servlet should obtain one StateFul Session Bean per client. I read in EJB 3.0 in Action that to do so I should use a jndi lookup and save the result of the lookup in an HttpSession. This works fine for me when I have a single client.
My issue is that when I have several clients, context.lookup returns the same SFSB for each client. This means that I end up having a single SFSB for the whole application. I've been browsing the web for a while now trying to find a solution but haven't had any luck yet.
The code I use to obtain and save the SFSB is the following:
HttpSession session = request.getSession(true);
DFMServiceRemote service = (DFMServiceRemote) session.getAttribute("DFMService");
if (null == service)
service = (DFMServiceRemote) new InitialContext().lookup("DFMService");
session.setAttribute("DFMService", service);
}Using different browser, I end up with different HttpSession but a single SFSB. The only workaround I found is to create the context with environment variables or properties. It then returns different SFSBs for different HttpSession. The workaround code is as below:
Hashtable<String, String> env = new Hashtable<String, String>();
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.evermind.server.rmi.RMIInitialContextFactory");
env.put(Context.SECURITY_PRINCIPAL, "oc4jadmin");
env.put(Context.SECURITY_CREDENTIALS, "welcome");
env.put(Context.PROVIDER_URL, "ormi://localhost:23791/DriverFatigue");
service = (DFMServiceRemote) new InitialContext(env).lookup("DFMService");My question is the following. How can I get a different instance of an SFSB every time I execute context.lookup without specifying properties.
Thanks in advance for any help,
Matthieu Siggen

I just did something similar in another project using JBoss instead of oc4j and didn't have any problem. I expect I missed a configuration file in oc4j or there is a conflict somewhere.

How to track the stateful Session Bean?

Hi all,
Am in a serious trouble. I have a message driven bean which will get initiated when some message gets dumped into the queue. I have got session bean which i use to process message which my message driven bean takes from the queue.
My problem is, lets say there are 3 msgs in the queue. lets say the messages be "aaaa", "aaaa" and "bbbb".
In this case, when i read the first message, i will create an instance of the session bean to process the message "aaaa". When i receive the second message still i create an instance to process the message "aaaa". When i get the 3rd message, i create an instance to process the message "bbbb".
My problem in this is, i want to create only one instance of session bean for the message "aaaa".
So once i create the instance for session bean for particular message, i need to store the object or something of the instance which i created along with the message. Please help me with what i can store with which i can reffer to the session bean again.
Please see the sample code too.
Thanks in advance,
Ashly
if(msg.equals("aaaa"))
First n;
Object obj = ctx.lookup("ejb/First");
FirstHome home = (FirstHome) PortableRemoteObject.narrow(obj, FirstHome.class);
n = home.create(msg);
}

Hi,
thanks for information. But i have one question. In a stateful session bean why do we have to store the Remote Interface on the client side.
I expected in the second jsp page when i do a lookup or create, the container/server should find out whether there is a session bean already created for this session if yes, then return that particular instance of the session bean else create a new one.
If this is not a possible case then a stateful session bean is nuthing but an instance of an object in the EJB container which does not get destroyed unless there is a time out or the remove method is called. It has nuthing to do with session because throughout the session I have to store the remote interface in the session context of the client( the client here means the jsp).
thanks in advance
Anurag

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.

"Sharing" a stateful session bean between two servlets, beans

Hello!
I just started to learn some java ee programming and was wondering how i would share one stateful session bean between two servlets.
I created the bean with @Stateful.
I tried to inject the stateful bean in both servlets by @EJB and i can manipulate the object, but each servlet seems to have its own object.
The bean has a remote interface that it implements.
What i also tried was to add the mappedName to the @Stateful expression. Something like: @Stateful(mappedName="name") and to use the bean by @EJB(mappedName="name") but it had no effect.
Im using glassfish 2.1 with netbeans 6.7.1 as my environment (standard settings)
dummy question, but i googled like hours and couldnt find anything : \
hope someone can help and sorry for my bad english
greets and thanks

Hi there!
I think you are searching for something like an application wide singleton. There is the possibility to define such one in the Glassfish admin console.
Hope this helps!

Howto call the @Remove method of a stateful session bean after JSF page ...

I use EJB3, JPA, JSF in my web application. There are 2 database tables: Teacher and Student. A teacher can have many (or none) students and a student can have at most 1 teacher.
I have a JSF page to print the teacher info and all his students' info. I don't want to load the students' info eagerly because there's another JSF page I need to display the teacher info only. So I have a stateful session bean to retrieve the teacher info and all his students' info. The persistence context in that stateful session bean has the type of PersistenceContextType.EXTENDED. The reason I choose a stateful session bean and an extended persistence context is that I want to write something like this without facing the lazy initialization exception:
<h:dataTable value="#{backingBean.teacher.students}" var="student">
<h:outputText value="${student.name}"/>
</h:dataTable>Because my session bean is stateful, I have a method with the @Remove annotation. This method is empty because I don't want to persist anything to the database.
Now, my question is: How can I make the @Remove method of my stateful session bean be called automatically when my JSF page finishes being rendered?

Philip Petersen wrote:
I have a few questions concerning the EJB remove method.
1) What is the purpose of calling the remove method on stateless session
bean?There isn't one.
>
2) What action does the container take when this method is called?It checks that you were allowed to call remove (a security check) and then
just returns.
>
3) What happens to the stateless session bean if you do not call the remove
method?Nothing
>
4) Is it a good practice to call the remove method, or should the remove
method be avoided in the case of stateless session beans?
Personally, I never do it.
-- Rob
>
>
Thanks in advance for any insight that you may provide.
Phil--
AVAILABLE NOW!: Building J2EE Applications & BEA WebLogic Server
by Michael Girdley, Rob Woollen, and Sandra Emerson
http://learnWebLogic.com
[att1.html]

How to get the Stateful Session bean instance in the second call

Hi,
I am new to EJBs. I have made a Stateful session bean on the first jsp page. In this page i am setting certain member variables of the EJB. Now in the second page i want to get these stored values in the EJB.
In the second page do I...
1. Store the instance of Remote Interface in the Session Context of the first JSP page and then in the second page get the Remote interface stored in its session context and call the business functions to get the values. If this is the case then what do u mean by Stateful Session beans??
P.S.- This works fine.
2. Try to get the Remote interface of that particular instance of the EJB(in which the values were stored) and call its business functions. IF this is possible. How do i do it??
thanks in advance
Anurag

Hi,
thanks for information. But i have one question. In a stateful session bean why do we have to store the Remote Interface on the client side.
I expected in the second jsp page when i do a lookup or create, the container/server should find out whether there is a session bean already created for this session if yes, then return that particular instance of the session bean else create a new one.
If this is not a possible case then a stateful session bean is nuthing but an instance of an object in the EJB container which does not get destroyed unless there is a time out or the remove method is called. It has nuthing to do with session because throughout the session I have to store the remote interface in the session context of the client( the client here means the jsp).
thanks in advance
Anurag

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

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.

Spawning thread in the stateful session bean

I ran into an interesting issue: I am spawning a thread inside
my stateful session bean's ejbCreate(...) method. The spawned
thread runs in an infinite loop until some stop signal. The
thread uses some BMP entity beans to access some data from DB,
it creates some BMP entity beans as well as creates another
stateful session bean in each iteration. The application ran
into a crash. Now I have a couple questions:
- First, is it an allowed operation to have a stateful session
bean spawn off threads? Am I violating the specs?
- Second, is it also allowed to have that thread create another
bmp entity bean and another stateful session bean? Again, am I
violating the specs also in here?
Your responses will be very much appreciated.
- Simon

From the EJB 2.0 Spec, Section 24.1.2:
<quote>
These networking functions are reserved for the EJB Container.
Allowing the enterprise bean to use these functions could compromise
security and decrease the Container’s ability to properly manage the
runtime environment.
• The enterprise bean must not attempt to manage threads. The
enterprise bean must not attempt to start, stop, suspend, or resume
a thread; or to change a thread’s priority or name. The enter-prise
bean must not attempt to manage thread groups.
<quote>
And, spawning threads in weblogic is highly discouraged in any
server-side component. An application should not be designed this
way.
Bill
Simon wrote:
I ran into an interesting issue: I am spawning a thread inside
my stateful session bean's ejbCreate(...) method. The spawned
thread runs in an infinite loop until some stop signal. The
thread uses some BMP entity beans to access some data from DB,
it creates some BMP entity beans as well as creates another
stateful session bean in each iteration. The application ran
into a crash. Now I have a couple questions:
- First, is it an allowed operation to have a stateful session
bean spawn off threads? Am I violating the specs?
- Second, is it also allowed to have that thread create another
bmp entity bean and another stateful session bean? Again, am I
violating the specs also in here?
Your responses will be very much appreciated.
- Simon

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

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

Stateful Session Bean Question

Similar Messages

Maybe you are looking for