• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Newbie threading / synchronization questions

 
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
High fellow ranchers,

I don't have much experience in thread programming and I am new to JSF and java so I have 3 strikes against me on this one i guess but here goes.

The site I am building has a servlet context listener that instantiates a singleton app manager which instantiates and retains a reference to a singleton member manager. So the application startup essentially creates the hierarchy of manager objects and stores the app manager in an AppBean which is ApplicationScoped.

The role of the member manager is to grab member records from a database on initialization and build them into member objects. The member objects are hidden within the member manager and any call to the manager to obtain a member or member list gets a memberproxy objects returned.

So the user logs in through a login page backed by a MemberBean that is session scoped. The memberBean object has methods for login, logout, creation, and deletion.

My understanding, and correct me if I am wrong, is that the MemberBean and the AppBean will require explicit synchronization because they are session and application scoped, respectively.

I assume I will have to implement synchonization or locking at multiple levels.
Level 1 would be to insure the integrity of each member and memberproxy object.
Level 2 would be to insure the integrity of the member manager's lists (list of members and memberproxies).
Level 3 may not be required but it seems logical to implement synchronization at the bean level since that is where the work begins when processing a request.

Just looking for general patterns or recommendations at this point. Thanks
 
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, I could give my standard spiel about why creating a custom login/security service is a really, really bad idea, but consider it said and let's move on.

Application scope beans are shared by multiple users, and, as you have noted, have concurrency issues. Session/View and User-scope beans don't have that problem. So what that means, in essence, is that any of the methods in the Application scope bean that can potentially be accessed by more than one user at a time should be defined as synchronized methods.

That's really all there is to it.
 
Rob Shoults
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Custom login/security service:

Yeah... I could see where a container based system has its advantages. For the site I am creating, it won't matter and so I am using this as an opportunity to see how a custom model might work (more of a training opportunity).

Synchronization:
I was assuming that Session/View Scoped object/class methods would also have to be synchronized. This eliminates the possiblity of duplicate submit actions occurring in close proximity from a single user. That may be overkill but my understanding is that implementing it to prevent even the unlikeliest event should not cause a significant performance hit. From what I have read, synchronization in java 5+ has a low uncontended lock performance overhead. Any additional thoughts on that?
 
Tim Holloway
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Rob Shoults wrote:Custom login/security service:

Yeah... I could see where a container based system has its advantages. For the site I am creating, it won't matter and so I am using this as an opportunity to see how a custom model might work (more of a training opportunity).



It's what it trains you for that makes DIY security such a bad idea. I made up a list of reasons why you should never attempt to "roll your own", and it runs to about 13 items. At the top of the list, however, is the fact that I've been in J2EE since before JSPs were invented and of all the DIY security systems I've encountered, at all the different places - including financial institutions and the military - not one of them has actually been secure. And most of them can be cracked in under 5 minutes by unskilled people.

So that's why I'm down on DIY security. Leave it to the people whose full-time job is security. Even they get exploited sometimes. But it's a lot, lot harder that way.


Synchronization:
I was assuming that Session/View Scoped object/class methods would also have to be synchronized. This eliminates the possiblity of duplicate submit actions occurring in close proximity from a single user. That may be overkill but my understanding is that implementing it to prevent even the unlikeliest event should not cause a significant performance hit. From what I have read, synchronization in java 5+ has a low uncontended lock performance overhead. Any additional thoughts on that?



I never worry too much about individual user sync. Issues there are only likely to arise if the request handling is taking a long time (which it shouldn't), if the user is really twitchy on the submit button, or if the client is an automaton, and therefore running at machine speeds. The one case where I would worry would be for stuff like payment functions, where duplicate transactions shouldn't be allowed. Most such systems just warn the user not to double-click, but that rates right up there with the "don't enter dashes or spaces in the credit card number" as far as I'm concerned.

For the most part, you should be able to get by with just synchronization on the application-scope objects.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic