Welcome to the new Gigaspaces XAP forum. To recover your account, please follow these instructions.

Ask Your Question

Threadsafe Remoting Services


I have been working with remoting services, and here is what I think I am seeing. As documented, XAP creates worker threads as needed (up to a configurable limit) to handle heavy loads on remoting services. It seems that these threads all refer to the same instance of the service bean (implicit Spring singleton scope I guess). This results in static and instance variable members of the bean being subject to consistency issues such as overwrite. To manage this, the developer must ensure the integrity of the variables using concurrency constructs.

The polling container, on the other hand, defaults to a single polling thread, but its configuration can be altered to allow more than one polling thread to be spawned. According to the documentation this results in the listener bean's variables being subject to overwrites by the different threads, similar to the situation with remoting services. For polling containers; however, there is a configuration option (Spring prototype scope) that allows each consumer thread to receive its own copy of the bean. This relieves the developer of the burden of ensuring that the consumer bean is thread-safe.

Is the above description accurate? Is there a case for supporting the prototype option for remoting service beans? Is there a better way to ensure the integrity of the remoting service bean's data?



{quote}This thread was imported from the previous forum. For your reference, the original is [available here|http://forum.openspaces.org/thread.jspa?threadID=2898]{quote}

asked 2009-02-23 08:36:02 -0500

subuta's avatar

updated 2013-08-08 09:52:00 -0500

jaissefsfex's avatar
edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted

Hi Dan

This is the intended behavior, and is common to most Java remoting
implementations (Spring remoting, plain Java remoting, etc) as well as
the Java servlet specification (it follows the flyweight design
In most cases, using a service-instance-per-thread or per-call
methodology would be an overkill and is not actually needed. Instead,
you can create local instances when needed or use a thread safe instance
only in places where you really have to (e.g. use AtomicInteger to count
the number of invocations).
As for GigaSpaces remoting, if you use async remoting (which uses a
polling container) you can use the spring prototype scoping the same way
as in a regular polling container.
If you're using Executor remoting, the prototype scope will not help you
as the bean is only injected (and therefore created) once to the
remoting service exporter.


answered 2009-02-23 09:43:36 -0500

uri's avatar
edit flag offensive delete link more

Hi Uri,

Thanks for the explanation.


answered 2009-02-23 09:57:02 -0500

subuta's avatar
edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2009-02-23 08:36:02 -0500

Seen: 208 times

Last updated: Feb 23 '09