|
You are right John, It just got out of my mind that
batch process is not a web client.
Thanks
Ashwani
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".
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".
|
