Defining Stateful Session Bean Methods as Idempotent or NonIdempotent

Hi,
          Is there any way to define a stateful session bean method as idempotent
          or non-idempotent. Is there a patch to do this if u want it in Weblogic
          6.0
          Thanks
          Sameer

No, not right now... but BEA is looking into it. It has not been slated for
          a product release.
          They understand that certain getXXX methods of a stateful session bean could
          be idempotent and will look at that in the future.
          Tyler
          "Sameer Wadkar" <[email protected]> wrote in message
          news:[email protected]..
          > Hi,
          >
          > Is there any way to define a stateful session bean method as idempotent
          > or non-idempotent. Is there a patch to do this if u want it in Weblogic
          > 6.0
          >
          > Thanks
          > Sameer
          >

Similar Messages

Plz help!! idempotent methods stateful session beans? (failover)

          plz help!! idempotent methods stateful session beans? (failover)
          Hi there,
          Im trying to failover my shopping cart implemented using stateful ejb, the replication
          is working but the failover is not (Object not found exception....).
          By design is hard to think on an stateful ejb using idempotent methods, but after
          checking the documentation in detail im completely confused, so im starting to
          wonder if i should use idempotent methods or manual retry in case one server is
          down.
          Plz take a loo at these explanations about faiolver in the WLS edocs.
          "....With clustered objects, automatic failover generally occurs only in cases
          where the object is idempotent.....Because of this, replica-aware stubs will not,
          by default, attempt to retry a method that fails after the request is sent but
          before it returns. This behavior can be overridden by marking a service idempotent..."
          BUT
          "By default, a stateful session bean's Home stub provides load balancing and failover
          for its method invocations to any clustered server where the bean is deployed...."
          So is possible to achieve automatic failover (not only load balancing) for stateful
          ejb without having to worry about state-changes or manual retry. (i know the retry
          is requiered if the server crashed just before finishing a transaction but this
          is not what im talking about).
          Any help will be highly appreciated
          Alan


          Ryan,
          Yes, im deploying using In-memory replication and clusterable elements, when try
          to invoke the method (after one of the nodes is down) i recieve an "java.rmi.NoSuchObjectException:
          Bean has been deleted".
          I believe all this could be related to some sort of issue with JNDI Lookup in
          the cluster, but haavent been able to get a clue to make it work....(almost desesperate
          by now)
          Alan
          "ryan upton" <[email protected]> wrote:
          >Alan,
          >
          >If the state isn't maintained during failover I would suspect a
          >configuration error. Have you set the <replication-type> element within
          ><stateful-session-clustering> tag in the bean's deployment descriptor?
          >
          >"Alan" <[email protected]> wrote in message
          >news:40e17cf7$1@mktnews1...
          >>
          >> Ryan,
          >>
          >>
          >> Maybe i didnt explain myself, in the scenario im dealing with I KNOW
          >the
          >method
          >> finished succesfully (example, the user succesfully added an item to
          >a
          >cart).
          >>
          >>
          >> Just after that one of the nodes goes down, and the user decides to
          >add a
          >new
          >> item (new invocation , not a retry of failed one) on the same session.
          >>
          >> This is the case in which failover should work automatically as you
          >say,
          >meaning
          >> the new method invokation should be able to retrieve the session state
          >info from
          >> the replica and switch the primary.....Well, this is the part wich
          >isnt
          >working
          >> :( as i understand it should transparently
          >>
          >> I believe could be a config issue , but have no way to make it work.
          >>
          >> Regards,
          >>
          >> Alan
          >> "ryan upton" <[email protected]> wrote:
          >> >
          >> >"Alan" <[email protected]> wrote in message
          >news:40e06296@mktnews1...
          >> >>
          >> >> Ryan,
          >> >>
          >> >> Thanks for clearing the both conditions a bit more, in this case
          >my
          >> >issue
          >> >has
          >> >> to do with the scenario #1 in which subsequent calls (invocations)
          >> >go to a
          >> >node
          >> >> which isnt avaliable(down), do you have any idea of in what conditions
          >> >the
          >> >"automnatic"
          >> >> failover would fail??? (meaning why the stub would try to dispatch
          >> >a call
          >> >to the
          >> >> same previous node)
          >> >>
          >> >> Thanks for the help again
          >> >>
          >> >
          >> >Subsequent calls won't go to a node that's down. That's the whole
          >> >point
          >> >;-). Failover is always automatic, what you are getting confused
          >on
          >> >is
          >> >automatic method re-execution upon failover which happens if the method
          >> >has
          >> >been marked as idempotent. The logic is this: if I failover to an
          >EJB
          >> >that
          >> >I know is still alive, I can't safely call the same method again.
          > Why?
          >> >Because I don't know how much of the method completed the last time
          >before
          >> >the previous bean's failure. So if the bean can yield multiple results
          >> >from
          >> >multiple invocations I had better play it safe and not re-execute
          >the
          >> >method
          >> >on the bean I failed over to (unless it's idempotent because in that
          >> >case it
          >> >doesn't matter how many times I call it, it always does the same thing).
          >> > In
          >> >scenario #1 and #2 failover is automatic and all new calls are executed
          >> >against the bean the client failed over to, but only idempotent methods
          >> >are
          >> >re-executed.
          >> >
          >> >
          >>
          >
          >

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]

Update object returned by a business method in stateful session bean

I have a business method in stateful session Bean returning an Object "myObject getObject()". This object can be modified by the client.
Is it necessary at the end to notify the bean about the changes with some kind of business method "setObject(Object myObject)"? or
the client and the bean have the same reference to the object and it isn't necessary?
Thanks

When an EJB returns a value, it is serialised across the wire and is effectively lost to the EJB. Any changes to the returned object by the client, will have to be notified by a call on the EJB, as in your post.
Dave

How create EJB 2.1 Stateful Session Bean in a EJB 3.0 Session Bean

Hi All,
We have been developing on EJB 2.1. We are now adding a module on EJB 3.0.
How can we "create" a stateful session bean with create method signature similar to create(String id)?
We have tried
// this is the remote interface
@EJB AddressBean abean;
But not working
Any help will be appreciated.

There is no explicit create() call for EJB 3.0 session beans. It doesn't really matter though
since you can accomplish the same thing by defining your own business method to act
as an initializer for whatever state you'd like. E.g.
@Remote
public interface FooInterface {
public void initialize(String id);
// ... other business methods
@EJB FooInterface fooRef;
fooRef.initialize("foo");
--ken

Stateful Session Bean Initialization (EJB 3.0)

Hi all!
In EJB 2.1 the initialization was with create (args) methods. NOw, how is it exploited? Create methods are no more there and there must be a way to send parameters to the stateful session bean when it is newly created...isn't it?
Thank you!

There is no pre-defined equivalent of a create method in EJB 3.0. If you want to initialize a
stateful session bean, just define a business method that the client should use as an initialization
method.

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

Handling Transaction in Stateful Session Bean

I wrote a public method like public void doTransaction()
it will call 2 private method, like: methodA and methodB
Both private methods have db accesss statement and will update the db. They got different db connection and will close the connection when method call finished.
How to include them to one transaction? I want to be able to rollback the job of the first method when I catch exception thrown by the second method.
I tried simply define transaction type of the public method to be Container and Required. But it doesn't work, the first method doesn't rollback. Of course I can let the 2 private methods share a same connection and commit after finishing calling them. But how if they are in different DB?

Ok... Here it goes...
You can do it in the following manner.
As you said you have got 2 private methods doing d/b updates and these are called from a public method.
Stateful session beans since associated with a client across methods, you can take advantage of it. Write your own user defined transaction.
Begin the transaction scope in your public before calling the 1st private method. Call the 2 methods in a try block. Once you are done with these methods, you can commit and end the transaction. If you get any exception, rollback the transaction in the catch block. Otherwise if u get any exception in the 2nd method, you can rollback the transaction there itself.
Stateful session beans lets u allow to spawn the bean managed transaction across methods. you can begin your transaction in one method and end it in a differnt method or you can end the transaction after calling the methods.
The problem you are dealing with can typically very well handled by writing bean managed transaction.
Hope this helps. If you need anymore clarity on my solution, please let me know.
-amit

Transaction inside a stateful session bean

I've a stateful session bean that represents a shopping cart.
It has the following checkout method():
<pre>
/* em.getTransaction().begin(); */
reasons.clear();
for(CartEntry ce : entries){
// get the book reference for the cart entry
Book relbook = books.findById(ce.getBook().getId());
if( ce.getQuantity()> relbook.getQuantity() ){
reasons.add("Item not availabel in this quantity");
// TODO: need to rollback
/*em.getTransaction().rollback();*/
throw new Exception();
} else{
// update book quantities
relbook.setQuantity( relbook.getQuantity() - ce.getQuantity() );
/*em.getTransaction().commit();*/
// end of conversational state
cancel();
</pre>
This method checks for the quantity of the items with respect to the quantity in the cart entries.
How can I perform a transaction here?
I'd like to rollback it before throwing the exception. And I'd like to commit it at the end,.
If I use the entity manager to get the transaction, I get this error:
Exception Description: Cannot use an EntityTransaction while using JTA.

Its sad to see someone using EJB technology and then completely throw all benefits of it out of the window. I highly advise you to look into Container Managed Transactions; learn what they help you to do and then apply it. When you know how, it will put a smile on your face as you'll see the transaction management stuff disappear before your eyes.
, from the time by which I decrement the item quantity in the database to the commit, no other transaction is decrementing the quantity of the same item as well??? Am I protected against this???Concurrency is a hard problem with no clearly defined answers to it other than "you need to design the code to guard against concurrency problems". In this specific case, the database protects against this happening by applying a row lock or a table lock while the transaction is active and you are making modifications. For more information about that, you should consult the documentation relating to your specific DBMS.

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

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 .... {

SAME EJB 3.0 Stateful Session bean for different JSP sessions returned

Forum,
I have a strange problem utilizing stateful session beans. Please note, that I am using jdeveloper for the following:
1) Here is a basic stateful session bean:
@Stateful(name = "DemoClass")
public class DemoClassBean implements DemoClass,
           DemoClassLocal, SessionSynchronization {
      public static int id=0;
      public DemoClassBean() {
      id++;
      public int getId() {
         return id;
      //... other methods
}2) This bean is accessed from a JSP for testing purpose, I am copying only the script used in JSP:
<%
   DemoClass bean = null;
   try {
      bean = (DemoClass) ((new javax.naming.InitialContext()).
                   lookup("DemoClass "));
      System.out.println("ID=" + bean.getId() );
      } catch (javax.naming.NamingException e) {
         // TODO
%>If this page is addressed by different clients, from different browsers, the same bean is returned.
Here is what I see in the logs:
ID=1
ID=1
ID=1
The same problem is being observed when this session bean is accessed from a JSF Backing bean.
What could be wrong? Is this a bug in oc4j / jdeveloper (version 10.1.3.3.0)?
Edited by: smw000000001 on Nov 17, 2008 10:52 AM

Hi,
The code for stateful is perfectly fine and working in a normal way. The way you are trying to implement the stateful session bean in your application is wrong.
think of binding the stateful session bean with HttpSession object.
So that you will get a unique stateful session bean object.

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 not

Stateful 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

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.

Defining Stateful Session Bean Methods as Idempotent or NonIdempotent

Similar Messages

Maybe you are looking for