If you quote the spec you should read it very very carefully. "The container may throw..." is just a recommendation for the container developer, not a must have. I had to experience this problem in a real world project, where ATG Dynamo Application Server did not throw such an exception on concurrent access to a stateful bean.
As I said in my first posting there should be no state in a stateless bean so no need to synchronize. Unless you share the client id explicitly you will also not get into the situation, that two different clients access a stateful bean at the same time. To make further discussion easier, Ashwani, you should tell us why you want to synchronize (is there a state in the instance, some static state, DB DB state?) and on what object this snychronization should happen (on EJB instance, on method for all instances, or on some member or static object?). Regards, Andreas. http://www.andiberg.de/ ________________________________ Von: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED] Im Auftrag von Kalra, Ashwani Gesendet: Freitag, 19. Mai 2006 07:37 An: EJB-INTEREST@JAVA.SUN.COM Betreff: Re: AW: Synchronizing ejb method You are right John, It just got out of my mind that batch process is not a web client. Thanks Ashwani ________________________________ From: Johan Eltes [mailto:[EMAIL PROTECTED] Sent: Friday, May 19, 2006 11:03 AM To: Kalra, Ashwani Cc: EJB-INTEREST@JAVA.SUN.COM Subject: Re: AW: Synchronizing ejb method I don't think the batch and the clients will get th same session id. That's the whole idea of stateful session beans - that each client gets its own instance and that the instance has affinity for requests from its owning "user" during the lifetime of the users session. I would recommend application-controlled database state management for locking out one type of client from the other (with stateless session bean). /Johan 19 maj 2006 kl. 06.15 skrev Kalra, Ashwani: No its not correct. Section 7.5.8 , Ejb 2.1 "Clients are not allowed to make concurrent calls to a stateful session object. If a client-invoked business method is in progress on an instance when another client-invoked call, from the same or different client, arrives at the same instance of a stateful session bean class, the container may throw the java.rmi.RemoteException to the second client[7] if the client is a remote client, or the javax.ejb.EJBException if the client is a local client. This restriction does not apply to a stateless session bean because the container routes each request to a different instance of the session bean class." I think there is no standard approach as Andreas said. My problem is that there is some batch process running and there is jsp page that can access the same method of ejb which I wanted to avoid. I think I can use statefull session bean so that at least second client gets the exception. Thanks Ashwani ________________________________ From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED] On Behalf Of Tareq Ayub Sent: Friday, May 19, 2006 7:55 AM To: EJB-INTEREST@JAVA.SUN.COM Subject: Re: AW: Synchronizing ejb method Refer to the EJB spec. The container will not allow multiple threads to use the same instance of an SLSB. From the spec - "The container must ensure that only one thread can be executing an instance at any time". Given that, why would you want to synchronize on an EJB method anyways ? Also, SLSB have no state (no instance variables). The same principle applies to SFSB in addition to the fact an instance is tied to a single client. Tareq On May 15, 2006, at 2:40 AM, Andreas Berg wrote: You shouldn't. The only reason to synchronize a stateless session bean is if your bean is not stateless. Then ask yourself why you chose a stateless bean for some stateful purpose. If you really want to synchronize your SLSB you need to think about the runtime environment. If all the instances of the SLSB run in a single JVM, you can use the standard Java synchronization features inside the bean to synchronize. But this doesn't work with a clustered environment. AFAIK there is no standard approach to solve this. Kind regards, Andreas. Andreas Berg Zelfi AG Hechtsheimer Straße 33 55131 Mainz Telefon: 06131-9064850 Telefax: 06131-9064853 [EMAIL PROTECTED] http://www.zelfi.com/ ________________________________ Von: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED] Im Auftrag von Kalra, Ashwani Gesendet: Montag, 15. Mai 2006 06:42 An: EJB-INTEREST@JAVA.SUN.COM Betreff: Synchronizing ejb method Hi, The client of my ejb can be an jsp or standalone java class. How can I synchronize access to the SLSB ejb method? I am using ejb2.0 version __________________ Regards Ashwani Kalra This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
