• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Listeners Thread Safety

 
Walid Abd Elsalam
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just wondering. I'm reading the HFSJ chapter on event Listeners (Context, Session, Request) and was wondering what's the verdict in terms of thread safety. Do they pretty much follow the same rules as per servlets?

For example:
Let's say that I have a static variable defined in a ServletRequestListener that keeps track of number of requests created. Would that be safe without having to synchronize on the class's lock?

The book doesn't say much about the lifecycle of a listener.
 
Frits Walraven
Creator of Enthuware JWS+ V6
Saloon Keeper
Pie
Posts: 2532
113
Android Chrome Eclipse IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think you are right having an static variable synchronzing on a class lock would work.

What about an instance variable where the read/update methods are synchronized -- that would work as well wouldn't it.

Regards,
Frits
 
Walid Abd Elsalam
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It should work of course.
What I'm really wondering about is the lifecycle of a Listener. Meaning do we have several instances running each per request (maybe a pool from which we draw a listener as an event occur to handle the event and then it's returned).
Or is it a single instance with events triggered queued for processing one by one. In that case it would be thread safe, except that you might want to re-initialize instance variables each time you process a new request.

The same goes for session and context listeners.

 
Frits Walraven
Creator of Enthuware JWS+ V6
Saloon Keeper
Pie
Posts: 2532
113
Android Chrome Eclipse IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The servlet spec doesn't say anything about a pool of listener instances.
It actually says:
"TheWeb container creates an instance of each listener class and registers it for event
notifications prior to the processing of the first request by the application"

My interpretation is that it is one instance per listener declaration.
 
Walid Abd Elsalam
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
From the Servlet Spec



SRV.10.5 Listener Instances and Threading
The container is required to complete instantiation of the listener classes in a Web
application prior to the start of execution of the first request into the application. The
container must maintain a reference to each listener instance until the last request is
serviced for the Web application.
Attribute changes to ServletContext and HttpSession objects may occur
concurrently. The container is not required to synchronize the resulting
notifications to attribute listener classes. Listener classes that maintain state are
responsible for the integrity of the data and should handle this case explicitly.



Seems to be a new thread of execution per request then. Just like servlets?
But what about context listeners?
And is only referring to thread safety for attributes, but how about Listener instance and class variables?
This is still a bit fuzzy for me
Is it vendor specific?
Is there any document out there about the lifecycle of a listener. In particular whether we have a pool of instances or threads of execution or a single instance running?

Anyone with some more info on this?
 
Frits Walraven
Creator of Enthuware JWS+ V6
Saloon Keeper
Pie
Posts: 2532
113
Android Chrome Eclipse IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
From this you could draw the following conclusions:
  • One listener instance per listener (defined in web.xml) which is referenced util the webapp closes down, so no pool of listeners
  • Events fired when attributes are being added/replaced or removed will access the attributeAdded/attributeReplaced or attributeRemoved methods of the listener concurrently. The webcontainer doesn't synchronize those events (e.g. 2 or more events can trigger the same method at the same time)
  • Listeners classes that maintain state (i.e. having instance variables or class variables) are responsible for the data integrity (i.e. should use synchronized methods to access and update)


  • What do you think?

    Regards,
    Frits
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic