Business Object Concurrency

[pradeep79]

Hi all,

I'm planning to use spring with Echo2 as the front end. I have already seached the web and haven't found any interesting articles of how to integrate Echo2 with spring. If anyone knows how it can be done please drop me a line.

My main question is concurrency management at business object level. If 100 clients want to run a particular method on a particular business object how does spring handle that?

If I don't configure it as a singleton, will spring created 100 instances of it?

If I configure it as a singleton, will it be thread safe? How will the locking happen? Do I have to program it with synchronisation?

I am used to program in PHP, there you don't have to worry about the concurrency issue, because the container manages it. In spring how can you manage that?

Your help will be much appreciated

Pradeep

[Andreas Senft]

My main question is concurrency management at business object level. If 100 clients want to run a particular method on a particular business object how does spring handle that?

Not at all. Invoking methods on an object has not much to do with Spring. At most you can decorate spring managed beans with AOP proxies which kick in on an invocation.

If I don't configure it as a singleton, will spring created 100 instances of it?

First you should clarify which kind of object you are talking about. If you are talking about domain model objects like User, Accout, etc. then these are usually not managed by Spring. If you are talking about Services, DAOs etc. then it depends on how you access them. If you retrieve a new prototype bean each time anew then you will have 100 instances. But usually you wire your beans once per collaboration and reuse them from then on.

If I configure it as a singleton, will it be thread safe? How will the locking happen? Do I have to program it with synchronisation?

Thread safety has nothing to do with that. You may encounter threading issues with a prototype bean as well.
As of synchronization: If your service is stateless (i.e. does not hold conversational state) then you do not need synchronization. If you can guarantee that invocations happen only from one thread then you do not need synchronization either.

I am used to program in PHP, there you don't have to worry about the concurrency issue, because the container manages it. In spring how can you manage that?

I do not have much knowledge of PHP but I would guess then that it's threading model is similar to that of java servlets. And I do not think that one could compare PHP with Spring like that as it serves another purpose.

[Alarmnummer]

Hi all,
My main question is concurrency management at business object level. If 100 clients want to run a particular method on a particular business object how does spring handle that?

Like Andreas Senft said, a stateless objects like most services (FireEmployeeService for example) don't need much concurrency control. Domain objects like Employee or Contract (entities) usually are isolated (confined) inside a single thread (transaction) and normally you would let the database take care of isolation (by setting the correct isolation level or in some cases do some locking). But it is very unlikely that you are going to use 'standard' synchronization techniques on entities.

there are three approaches of dealing with concurrency:
-immutability
-confinement
-synchronization

Synchronization normally is the hardest one.. so if you can get away with one of the others, you are a lucky man.

I am used to program in PHP, there you don't have to worry about the concurrency issue, because the container manages it. In spring how can you manage that?

Spring doesn't handle concurrency control for you. In your case you probably get away with confinement in combination with transactions and maybe some database locking.

[al0]

...
Spring doesn't handle concurrency control for you. In your case you probably get away with confinement in combination with transactions and maybe some database locking.

I dare to say that DB transactions and locking have (almost) nothing to do with thread synchronization in the JVM. They shall not be mixed (in the developer's head ) or considerer as substitute.

There were some discussion about this in this forum few month ago.
You may try search for them.

Regards,
Oleksandr

[Alarmnummer]

I dare to say that DB transactions and locking have (almost) nothing to do with thread synchronization in the JVM.

Who said it was?

They shall not be mixed (in the developer's head ) or considerer as substitute.

I don't agree. You can use various techniques to deal with concurrency control You could add synchronization yourself on entities, but in most cases the database can take care of synchronization for you (much simpler). By placing the responsibility of synchronization on the database, you just need to focus on isolation.

[al0]

Who said it was?


I don't agree. You can use various techniques to deal with concurrency control You could add synchronization yourself on entities, but in most cases the database can take care of synchronization for you (much simpler). By placing the responsibility of synchronization on the database, you just need to focus on isolation.

Absolutely not - concurrency in JVM is about in-memory concurrency between different thread for the same instance of the object. DB has no way to know about it, not saying about managing/resolving it.

If you speak about concurrency for persited objects in DB, you are right, but even in this case, if second-level cache is involved, DB does not control it completely.

Regards,
Oleksandr

[pradeep79]

Thank you for all your contributions. Let me clarify this a bit more..

I have a customer class, which is a JavaBean with all the customer attributes.

Then I have a customerManagement class that implements the business logic. In this case a simple search operation that puts the results in an ArrayList.

Now, the customerManagement class will be accessed by several users simultaneously to do a search and the search will return different results in the ArrayList based on the criteria of each user, so it is statefull and cannot be a singleton, correct? Please correct me if I'm wrong here.

Customer class will have several instances in the customerManagement class, so I assume that will definitely be a prototype, correct?

Next, I have a customerDAO class that connects to the database with hibernate. This is injected into customerManagement class. I assume it will be a singleton, correct?

Interesting question is, because we have several instances of customerManagement class, if all of these will try to access one method, say getCustomers(String criteria) in customerDAO simultaneously, how will it handle concurrency? Being a singleton and no locking implemented will it end up in disaster? Do I have to synchronize getCustomers(String criteria) method? I'm totally lost here? Please correct me if I have got the whole thing wrong.

I will appreciate all your comments

Cheers
Pradeep

[Andreas Senft]

Then I have a customerManagement class that implements the business logic. In this case a simple search operation that puts the results in an ArrayList.

One could argue that Customer related business logic should go into the Customer class (as the domain driven design approach suggests). But that only as an aside.

Now, the customerManagement class will be accessed by several users simultaneously to do a search and the search will return different results in the ArrayList based on the criteria of each user, so it is statefull and cannot be a singleton, correct? Please correct me if I'm wrong here.

If your class does not hold any conversational state (the simple case would be that the methods operate only on their arguments) then it is not stateful and does not require any synchronization from a technical point of view.

Customer class will have several instances in the customerManagement class, so I assume that will definitely be a prototype, correct?

I would refrain from managing Customer instances via Spring. That does not make sense. Usually you store these instances in a database.

Next, I have a customerDAO class that connects to the database with hibernate. This is injected into customerManagement class. I assume it will be a singleton, correct?

If it, as is usual, holds no conversational state, then the answer is yes.

Interesting question is, because we have several instances of customerManagement class, if all of these will try to access one method, say getCustomers(String criteria) in customerDAO simultaneously, how will it handle concurrency? Being a singleton and no locking implemented will it end up in disaster? Do I have to synchronize getCustomers(String criteria) method? I'm totally lost here? Please correct me if I have got the whole thing wrong.

The keypoint is again the conversational state of an object which decides of the need to synchronize. I strongly recommend to read a book or tutorial on Java concurrency (see http://www.javaconcurrencyinpractice.com/ , http://g.oswego.edu/dl/cpj/ or http://java.sun.com/docs/books/tutor...ncy/index.html)

Regards,
Andreas

[Alarmnummer]

Absolutely not - concurrency in JVM is about in-memory concurrency between different thread for the same instance of the object. DB has no way to know about it, not saying about managing/resolving it.

The JVM provides synchronization on objects. The database provides synchronization on entity. It is just a location where you are doing concurrency control.

Depending on the situation, you can choose which technology you want to use. My preferred solution for standard webapplications is confinement in the JVM and let the database worry about synchronization.

If you speak about concurrency for persited objects in DB, you are right

That is the concurrency control you find in 99% of the most standard webapplications and that is why I suggested it to the topic starter.

, but even in this case, if second-level cache is involved, DB does not control it completely.

I didn't say the database always should be used as a replacement for JVM concurrency control. But in most standard webapplications, the database does a far better job at it than most programmers (including me) ever will.

[al0]

There are 2 types of concurrency - one about stored data (you may name them entities) and one for your in-memory structures. DBs are perfect for 1st type of cocurrency (as far as competitors do not share the same connection), but are absolutely helpless in second one as they even do not know that it ever exists.

If "typical" application as you said relies on DB for concurrency control it just means that in-memory concurrency control problem is already solved - likely, by the simpliest possible approach, i.e. by avoiding it, e.g. by stateless services and object-per-thread approach for business objects.

Once more - these 2 types of concurrency are independent and hardly related to each other.

BTW, all this discussion is quite funny for me, as I'm much more DB developer then Java developer and am used to say to others "Do not try to reinvent the wheel and rely on DB as much as possible".

Regards,
Oleksandr

The JVM provides synchronization on objects. The database provides synchronization on entity. It is just a location where you are doing concurrency control.

Depending on the situation, you can choose which technology you want to use. My preferred solution for standard webapplications is confinement in the JVM and let the database worry about synchronization.


That is the concurrency control you find in 99% of the most standard webapplications and that is why I suggested it to the topic starter.


I didn't say the database always should be used as a replacement for JVM concurrency control. But in most standard webapplications, the database does a far better job at it than most programmers (including me) ever will.