This week's book giveaways are in the Java EE and JavaScript forums.
We're giving away four copies each of The Java EE 7 Tutorial Volume 1 or Volume 2(winners choice) and jQuery UI in Action and have the authors on-line!
See this thread and this one for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Business Layer concurrency Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Business Layer concurrency" Watch "Business Layer concurrency" New topic
Author

Business Layer concurrency

S. Thakker
Ranch Hand

Joined: Aug 11, 2011
Posts: 45
I just had a quick question. Are you guys handling Business service concurrency as well?

So what if Thread 1 comes in, get a lock on rec #2, then Thread 1 completes and books the room. Then thread 2 comes in at the same time and is waiting for the lock. Do you have some type of kick-out on the update method to say that if the Room is not available, then throw an exception?

This is how I implemented it.. I was wondering what you guys did.

Because is doing this enough??

if(room.isAvailable()) {
database.update(recNo);
} else throw RecordNotFoundException.

Or would you have to do what I did, and if two records get a lock, the second one that tries to update is kicked out.

This is the call from the business service.
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5216
    
  12

My book room method (in the business service) contains all necessary business logic. And after a record is locked successfully I read the record again to verify if the room is still available and was not already booked by another client (thread). If it is, a specific business exception is thrown (and the record is unlocked). Otherwise record is updated and unlocked.

Hope it helps!


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
http://www.javaroe.be/
S. Thakker
Ranch Hand

Joined: Aug 11, 2011
Posts: 45
Its a synchronized block correct? I am wondering if this is a must requirement... I am guessing it would be
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5216
    
  12

No, it's not a synchronized block. That's not needed at all. It even prevents your application from being a multi-threaded application (and thus could result in failure).
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2265
    
    3

S. Thakker wrote:Are you guys handling Business service concurrency as well?


Hum... no. Only in the Data class (which is just what is required).


So what if Thread 1 comes in, get a lock on rec #2, then Thread 1 completes and books the room. Then thread 2 comes in at the same time and is waiting for the lock. Do you have some type of kick-out on the update method to say that if the Room is not available, then throw an exception?

This is how I implemented it.. I was wondering what you guys did.

Because is doing this enough??

if(room.isAvailable()) {
database.update(recNo);
} else throw RecordNotFoundException.

Or would you have to do what I did, and if two records get a lock, the second one that tries to update is kicked out.

This is the call from the business service.


Hum... I don't think that's gonna work. Because if both Threads come at the same time, both of them will get true for the room.isAvailable() method. Before updating the record, you should call the lock() method, verify if the client id of the record is still empty; if so, then you go ahead and update the record and unlock the record, otherwise, throw a business exception and unlock the record. Something like this:



Cheers, Bob "John Lennon" Perillo
SCJP, SCWCD, SCJD, SCBCD - Daileon: A Tool for Enabling Domain Annotations
S. Thakker
Ranch Hand

Joined: Aug 11, 2011
Posts: 45
Yes, that code is executed after the lock method... For roel, I was talking about synchronizing the update with the check, however I now realize the otehr threads are waiting on the lock, so theres no threat
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5216
    
  12

S. Thakker wrote:however I now realize the otehr threads are waiting on the lock, so theres no threat

 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Business Layer concurrency