• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Tim Cooke
  • Liutauras Vilda
  • Jeanne Boyarsky
Sheriffs:
  • Paul Clapham
  • Rob Spoor
  • Junilu Lacar
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Piet Souris
  • Carey Brown
Bartenders:

Behaviour of IOC singleton scope or prototype scope during simultaneous access of website.

 
Ranch Hand
Posts: 2618
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have a doubt regarding behaviour of IOC singleton scope or prototype scope during simultaneous access of website.

The hibernate DAO object is getting instantiated using Spring IOC. What will happen if the scope of this IOC is kept as singleton. If multiple users try to access this website, will they get the same access (which can be an issue if both do updates using it). OR will the second user wait to get this singleton object until the first one is done with it? Should the scope be kept as prototype instead for this reason?

thanks


 
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If the bean is a Spring singleton, then there will be only one object which is shared for everything. There is no automatic synchronization. It would be a bad idea to synchronize it, because that would make your webapp not scalable. Imagine that you have 100 users logged in at the same time, and they want to go to some page for which a query is necessary... they would have to do the query one by one. That would be very inefficient.

The fact that the DAO is shared is not a problem as long as the DAO does not have state (member variables).
 
Monica Shiralkar
Ranch Hand
Posts: 2618
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Does that mean that if scope is singleton and say 2 multiple users are trying to access the web page the second user will have to wait until first one is done with it? Is this true ?

Or

the two users will get the same object and work on the same object which may be an issue.

Which of these is true?

thanks
 
Ranch Hand
Posts: 672
4
Eclipse IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Monica. Shiralkar wrote:Does that mean that if scope is singleton and say 2 multiple users are trying to access the web page the second user will have to wait until first one is done with it? Is this true ?


If a bean in singleton, this is not true. Single bean in shared between them.

Monica. Shiralkar wrote:the two users will get the same object and work on the same object which may be an issue.


Two users will get the same object. I don't know what issue you are talking about, but as Jesper mentioned, if DAO does not have member variables, it should not be a problem.
 
Monica Shiralkar
Ranch Hand
Posts: 2618
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

If a bean in singleton, this is not true. Single bean in shared between them.



If it is a singleton will it not happen. Suppose 2 users are accessing the website same time. User A does a banking transaction and does update. User B also does update. User A's data gets updated in user B's account.?

thanks
 
Prasad Krishnegowda
Ranch Hand
Posts: 672
4
Eclipse IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Monica. Shiralkar wrote:If it is a singleton will it not happen. Suppose 2 users are accessing the website same time. User A does a banking transaction and does update. User B also does update. User A's data gets updated in user B's account.?


let me understand what you are asking.. say there is an DAO object, which updates the database with users balance, and there is an Account class with field as balance, so when user A and user B does update at the same time, will user B's balance get updated to user A's balance?

Here DAO object can be singleton, but it should make sure that Account object is not an member variable and is passed to the updateBalance method of the DAO class.
 
Monica Shiralkar
Ranch Hand
Posts: 2618
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks all. I was under wrong impression that if object is singleton and accessed simultaneously then all users get same Object and it can be modified incorrectly by all users at once whereas in reality all will get different copy of objects and cannot modify each other's object incorrectly. Is that correct . In that case what difference has it made then to keep the bean Singleton instead of Prototype.
 
Prasad Krishnegowda
Ranch Hand
Posts: 672
4
Eclipse IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

I was under wrong impression that if object is singleton and accessed simultaneously then all users get same Object and it can be modified incorrectly by all users at once whereas in reality all will get different copy of objects and cannot modify each other's object incorrectly. Is that correct.


No. If a bean in singleton, then there is only one object created.
 
Monica Shiralkar
Ranch Hand
Posts: 2618
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Prasad Krishnegowda says

No. If a bean in singleton, then there is only one object created.



If there is only 1 object created. If User1 tries to access this object user1 will get it. If user2 tries to access this object User2 will get it. If user1 is doing some operation on this object (e.g banking transaction) and user 2 is calling update on this object, will user2 not update user1's data as they are working on same object.

thanks
 
Prasad Krishnegowda
Ranch Hand
Posts: 672
4
Eclipse IDE Spring Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

If there is only 1 object created. If User1 tries to access this object user1 will get it. If user2 tries to access this object User2 will get it. If user1 is doing some operation on this object (e.g banking transaction) and user 2 is calling update on this object, will user2 not update user1's data as they are working on same object.


If the bean does not have member variables then it will not be a problem, if it has member variables, then as you say user2 will update object and when user1 does update, it will cause issues.

Take example below,

If a bean is designed as above and its a singleton, then as you say when user1 and user2 access this bean, they get same object, and say user2 sets the accountBalance object with new balance, and user1 inserts it into database, it will cause issues, as accountBalance is an member variable here, and is overwritten by user2.

Consider, below code now.


Now, when user1 and user2 access this bean, they get same object, but user1 calls updateAccountBalance, it will pass its balance, so even when user2 is accessing this bean, it will not overwrite/have issues with update.

 
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Only one object of Class will be created for singleton and all instance variables will be shared among two different thread (request) but thread do not share local variable instance.
Check this link
 
Prasad Krishnegowda
Ranch Hand
Posts: 672
4
Eclipse IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Only one object of Class will be created for singleton and all instance variables will be shared among two different thread (request) but thread do not share local variable instance.


so, what are you trying to say, its fine even if we have member variables in singleton?
No, it should not be fine, just run the example i provided, you will find it out.
 
Dinesh Pise
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Prasad Krishnegowda wrote:

Only one object of Class will be created for singleton and all instance variables will be shared among two different thread (request) but thread do not share local variable instance.


so, what are you trying to say, its fine even if we have member variables in singleton?
No, it should not be fine, just run the example i provided, you will find it out.



I just want to tell that if a variable is instance variable with singleton then same object will be shared among different thread, if thread A update instance variable int count as 10 then count value will be 10 for all thread.
 
Rancher
Posts: 2759
32
Eclipse IDE Spring Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Monica. Shiralkar wrote:Prasad Krishnegowda says

No. If a bean in singleton, then there is only one object created.



If there is only 1 object created. If User1 tries to access this object user1 will get it. If user2 tries to access this object User2 will get it. If user1 is doing some operation on this object (e.g banking transaction) and user 2 is calling update on this object, will user2 not update user1's data as they are working on same object.

thanks



Monica,

Like Jesper said, this is exactly why you should'nt keep state; ie; user data in member variables. I don;t know how familiar you are with multi-threading concepts, and how they relate to variables in Java. If you aren't, I suggest that you forget Spring for now, and try to understand multi-threading first

To underscore the point. This code is not thread safe


This code is thread safe




Logically both pieces of code are equivalent, and in a single threaded application they will both work fine. However, when you have a multithreaded application, the first one is not safe. The second one is. If you can't figure out why, I suggest that you drop Spring for a while, and learn multi-threading. People who designed and teach Spring assume that you are familiar with multi-threading.

I'll give you the answer here.

In the DAO.save method in the second code sample, the variables bean is locally scoped. In Java, every thread gets it's own copy of local variables. So, when controllerMethod is callled on 2 threads, each thread has it's own instance of bean. Each thread passes it's own instance to the DAO.save method. Since, the bean parameter in DAO save is locally scoped, each thread has it's own bean parameter that has a reference to it's own bean instance.

In the DAO of the first code sample, the DAO has a member variable called bean. Member variables are shared among threads. All threads calling the DAO, will have the same member variable. So, when controller method is called on 2 threads, each thread has it's own instance of bean. Both threads will set the bean member on DAO class. This means that one of them might overwrite the other. THis means that when both threads call save at the same time, one of them will be saved twice, and other will be lost. This is a bug.

This is one of the common ways you can introduce multi-threading bugs in your application. Java Concurrency In Practice is an excellent book to understand the practical implications of multi-threading in Java. Every person who builds web applications should read this before building web applications.
 
Monica Shiralkar
Ranch Hand
Posts: 2618
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks to everyone for detailed explanations.


I suggest that you drop Spring for a while, and learn multi-threading. People who designed and teach Spring assume that you are familiar with multi-threading.



Yes. My exposure to multi threading had been the multi threaded core java project I had created by creating a thread pool and doing the activity simultaneously for multiple threads.

However in this case we are discussing of the Spring web application I did not know that automatic multi threading will happen without explicitly doing it. After your explanation I am understanding this that automatic multi threading will happen.



Member variables are shared among threads. In Java, every thread gets it's own copy of local variables.



I am trying to understand it in this way that for the variables declared inside the run method there will be a copy for each thread whereas for class variables (which were obviously outside run method) these variables were shared between multiple thread. However I am wondering that main method is also a thread then why variables inside it are shared by all.



THis means that when both threads call save at the same time, one of them will be saved twice, and other will be lost. This is a bug.



For the first case (not thread safe) : Can that situation arise that both threads call save at the same time. What I was thinking is that to us it may appear that the save is called at the same time but there will be a difference may be in microseconds by which it will be decided that which one called first. Is it not? And I understand that in that case there will be improper updates but why would one be saved twice.

thanks
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic