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
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 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".
===========================================================================
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".
|