aspose file tools*
The moose likes JSF and the fly likes Newbie threading / synchronization questions Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » JSF
Bookmark "Newbie threading / synchronization questions" Watch "Newbie threading / synchronization questions" New topic
Author

Newbie threading / synchronization questions

Rob Shoults
Greenhorn

Joined: Nov 06, 2011
Posts: 14
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
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16142
    
  21

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.


Customer surveys are for companies who didn't pay proper attention to begin with.
Rob Shoults
Greenhorn

Joined: Nov 06, 2011
Posts: 14
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

Joined: Jun 25, 2001
Posts: 16142
    
  21

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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Newbie threading / synchronization questions