Re: Scheduling and re-scheduling
Re: Scheduling and re-scheduling
- Subject: Re: Scheduling and re-scheduling
- From: Mike Schrag <email@hidden>
- Date: Sat, 4 Apr 2009 12:43:47 -0400
ScheduledExecutorService, no question ... If you don't, I would write
it with an someObject.wait(sessionTimeout) and someObject.notifyAll
when you ping the session to keep it alive, at which point your code
can decide if it needs to perform its action or resleep. Definitely
don't poll, but regardless, I wouldn't write this yourself.
java.util.concurrent will do something better than either of us can
come up with. The guys who wrote that stuff are pretty damn smart.
ms
On Apr 4, 2009, at 11:14 AM, Stamenkovic Florijan wrote:
Hi all,
Though a JavaClient question, it is more about Java, then about WO,
so please ignore the JC aspect of it...
I am looking for the best way to deal with the following requirement:
- I am watching (from the JavaClient side) for the server-side
session timing out
- I want to perform action X a specified amount of time before the
session times out
- i can observe requests being made to the session (from the client
side), and use this to know when X needs to execute
So, the crux of the problem is: re-scheduling action X.
I can think of two reasonably decent ways of dealing with this:
1. Have a daemon thread poll a long variable to see when the last
request to the session occurred, and have my request tracker just
update the same variable with System.nanoTime().
What I like: it's simple and clean, the request tracker does
minimal work.
What I don't like: the daemon thread needs to check this at a
reasonably small interval, I think each half a minute or so.
2. Use a ScheduledExecutorService to schedule action X. Hold the
reference to ScheduledFuture, cancel it every time that the request
tracker informs of a request being made, and immediately reschedule.
What I like: It relies of java.util.concurrent, which is said to be
a GoodThing.
What I don't like: The reaction to each request is not as light-
weight.
Considering that this is a JC situation, and it is possible and
probable that requests are made very frequently, I think the first
solution might be more appropriate. Any thoughts on this? Also, does
anyone know a better way to handle this situation? I am digging
through java.util.concurrent, but I don't see anything focused
specifically on this kind of a scheduling problem.
Thanks,
F
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden