wood burning stoves 2.0*
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes About @AccessTimeout definition 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 » Certification » EJB Certification (SCBCD/OCPJBCD)
Bookmark "About @AccessTimeout definition" Watch "About @AccessTimeout definition" New topic
Author

About @AccessTimeout definition

Himai Minh
Ranch Hand

Joined: Jul 29, 2012
Posts: 775
On p.26 of Frit's notes,

2.4.8 @AccessTimeout
Timeouts can be specified via metadata so that a blocked request can be rejected if a lock is not acquired within a certain amount of time...
eg. @AccessTimeout(value=5, unit=TimeUnit.SECONDS)


I guess what is meant is "a client's request can be rejected if a lock is acquired by this client for a certain amount of time."
For this example, if a client has been acquiring a write lock for 5 seconds, this client is rejected.


Frits Walraven
Creator of Enthuware JWS+ V6
Bartender

Joined: Apr 07, 2010
Posts: 1696
    
  25

I guess what is meant is "a client's request can be rejected if a lock is acquired by this client for a certain amount of time."

No, a client's request can be rejected if a lock is NOT acquired by this client for a certain amount of time (because another client has that lock)
Himai Minh
Ranch Hand

Joined: Jul 29, 2012
Posts: 775
So, @AccessTimeout (value = 5, unit=TimeUnit.SECONDS) means the first client acquires a lock while a second client waits for this lock. If the second client waits for the lock for over 5 seconds, the second client will be time out. The first client still has the lock , maybe forever ?

From the API, it says :

By default, clients are allowed to make concurrent calls to a stateful session object and the container is required to serialize such concurrent requests. The AccessTimeout annotation is used to specify the amount of time a stateful session bean request should block in the case that the bean instance is already processing a different request. Use of the AccessTimeout annotation with a value of 0 specifies to the container that concurrent client requests to a stateful session bean are prohibited.


According to this API specification, does it mean a client should wait forever for the bean if this bean is processing a different request forever?
Himai Minh
Ranch Hand

Joined: Jul 29, 2012
Posts: 775
I think I now understand this point from EJB in Action now:

3.4.8. Using stateful singleton session beans effectively
...
The wait times per client will vary—some will have one second whereas others might wait for a bit longer. A singleton thus needs to be divided into write (@Lock(LockType.WRITE)) and read (@Lock(LockType.READ)) methods. The write method updates data and thus requires the exclusive lock. The read method doesn’t require an exclusive lock and thus multiple clients can concurrently access the data.

If a write method may take a long time, it should be annotated @AccessTimeout if you don’t want the code waiting for an indeterminate amount of time.

This annotation can also be used to enforce a certain level of service—if the method is taking too long, an exception raising the method as a problem can go a long way toward resolving performance issues.


In this quote, the underlined statement, it means if a developer does not want the client to wait for an indeterminate amount of time, @AccessTimeout is needed for the write method.
That means, the client will not wait, if the stateful or singleton bean takes forever to write.

In my opinion, it sounds "unfair" for the client to give up waiting , but that is how @AccessTimeout works.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: About @AccessTimeout definition