Are Spring business Service Components Thread safe?

[Ahad]

Hello all,

Currently I am using Spring as the core framework for a architecture of a large scale Hospital Management System. In designing the architecture I am thinking whether the business operations would be thread safe. Its a service oriented architecture.....And the Service provider classes(Which provide the business service to the clients or external world) uses Business Service classes through a Common gateway....This central gateway(A Facade essentially) takes the appropiate service object from the Spring Context and executes the operation.....In the db layer I am planning to use both hibernate as well as pure JDBC....through Spring Template..offcourse.... Now my question is do I need to make the common business operation of the Gateway synchronized? How much it puts burden in the System?

Regards,

Abdul Ahad
Lead Design Engineer
Sikraft Solution Ltd.

[tentacle]

Now my question is do I need to make the common business operation of the Gateway synchronized?

If you use Spring's middle tier components for transaction management and your service classes do not hold state other than persistence artifacts (datasource, Hibernate session factory, ...) your classes are perfectly thread-safe. The Spring application context is thread-safe, taking care of synchronization if and where required.

You can read more on thread-safety in Spring in this article.

[Rod Johnson]

Generally there are no thread safety issues in the service layer. For example, look at typical SLSBs: they are given pooling by the container, but in reality don't need it, as a typical SLSB has no read-write instance variables after it's configured.

In the rare cases where you strike something that isn't naturally threadsafe in the service layer, you can use synchronization. Or you can use Spring's own pooling capability (see the AOP chapter in the Reference Manual).

What you're describing with data access will be completely threadsafe as far as Spring code is concerned.

[scesbron]

Just a question about synchronization.

It seems difficult for me to use method level synchronization in the service layer because of the programming to interfaces design choice.
I cannot add the synchronized keyword to the method in the implementation class of my service. If I do so, my service is not fully synchronized because transaction commit will occur outside synchronization.
As I don't want to let synchronization demarcation to the client side, the only solution I can find is using a synchronization keyword in my service declaration in my applicationContext.xml
Does this makes sense ? Do you have any other solution to my problem.

Here is a bit of code to explain my problem

public class Action
{
  public void process()
  {
    // I want this call to be synchronized but don't want to declare synchronization here
    getMyService().doSomething();
  }
}
public interface MyService
{
  void doSomething();
}
public class MyServiceImpl implements MyService
{
  // Synchronization here is not truly effective as transaction commit 
  // occurs outside the method
  public synchronized void doSomething()
  {
    // do
  }
}

[Alarmnummer]

What is the reason you want to use synchronisation? If there is no shared state, there is no need for synchronisation. Btw shared state in de db doesn`t count because the db-transaction will protect you for concurrency problems...

So... do you have shared state? If not.. there is no need for synchronisation.

[edit]
If you make all service methods synchronized there are going to be a few problems:
1) deadlock problems (if services use each other)
2) performance problems. If you block a complete service because someone is using it -> every other user has to wait.. so.. your application will be extremely slow.

[scesbron]

Maybe it is quite an unusual problem.
I have some kind of State object in the database. A lot of different threads call a service that change the properties of this State object (mainly a date). I don't want to throw exception if there is concurrent update to my object. I want my threads to change my State object one after the other.
The synchronisation is the only way I found to achieve that but there is maybe a better solution

Seb

[Alarmnummer]

Maybe it is quite an unusual problem.
I have some kind of State object in the database. A lot of different threads call a service that change the properties of this State object (mainly a date).

You don`t have too. If 2 users need to access the same object, the second should block untill the first has finished. This is part of your transaction.

The synchronisation is the only way I found to achieve that but there is maybe a better solution
Seb

Yes... there is: transactions.

[scesbron]

Sorry but for me this is true if you do pessimistic locking.

With optimistic locking, you can have two concurrent users that modify the same object. You can have two behavior in this case :
- The second one override what the first one did.
- You have a version check or something like that and the second one fails because of the modification made by the first user

Seb

[Alarmnummer]

Sorry but for me this is true if you do pessimistic locking.
With optimistic locking, you can have two concurrent users that modify the same object. You can have two behavior in this case :
- The second one override what the first one did.
- You have a version check or something like that and the second one fails because of the modification made by the first user

That is correct. But if you know the solutions, why are you trying to synchronize a complete service (in essence you are blocking a complete table...and not a single record).

[manifoldronin]

With optimistic locking, you can have two concurrent users that modify the same object. You can have two behavior in this case :
- The second one override what the first one did.
- You have a version check or something like that and the second one fails because of the modification made by the first user

With optimistic locking, an exception is thrown when the version check fails, but it doesn't mean you have to let the exception propagate all the way up. You could catch it, resynchronize the in-memory state with what's in db, and possibly try again.

Besides in-memory synchronization won't in a clustered envoronment anyway.