Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
Message-ID: <3F3C2486.5070700@dehora.net>
Date: Fri, 15 Aug 2003 01:08:38 +0100
From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.4) Gecko/20030624
MIME-Version: 1.0
To: geronimo-dev@incubator.apache.org
Subject: Re: Timer Service
References: <Pine.LNX.4.44.0308141410120.3249-100000@www.princetongames.org>
In-Reply-To: <Pine.LNX.4.44.0308141410120.3249-100000@www.princetongames.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Aaron Mulder wrote:
> On Thu, 14 Aug 2003, Jeremy Boynes wrote:
> 
>>Please review the spec in detail - the EJB Timer Service has requirements
>>for persistent timers and IIRC notifications for events that happened when
>>the server was down.
> 
> 
> 	True, but I think we could write something simple using a file for
> persistence and java.util.Timer if we wanted to meet the minimum
> requirements.  There is no facility in the spec for cron-style scheduling
> -- the only scheduling options are millisecond offsets, IIRC.  Granted, we
> could certainly integrate a fancier package and offer more "value added"
> features.  I'm trying to say I don't think we *need* to go there unless we
> want to.

The only real downside to Timer it is the API. You have to cache a 
ref to the TimerTask to cancel it later - you can't just ask the 
Timer to cancel a task of a given name. You also can't pause or 
alter the schedule a TimerTask, but that's just a matter of doing 
cancel() and reschedule() against a cached ref. A Timer can be 
wrapped with any extra functionality later and it would save you 
writing the core scheduler from scratch. I wouldn't bother not using 
java.util.Timer.

Bill de h�ra