I Think the Weblogic Time API has been deprecated. Anyway , We now are also thinking of using JMS instead of spawning of threads in the Appserver. The alternate architecture is Create a JMS queue and add report request objects to that queue, Schedule the object to run in 30 mins(Weblogic JMS has a scheduling API for 6.1). After 30 mins, the JMS creates a Message driven bean instance which reads the external DB and checks to see if data ready, if it is , it generates the report, else adds the same object to the queue again to run in 30 mins. Any ccomments? Sounds simple , but not sure if I missed something.
----- Original Message ----- From: Albert Pi <[EMAIL PROTECTED]> Date: Thursday, September 19, 2002 1:24 pm Subject: Re: J2EE Scheduling Architecture > Sunder: > I use the same way like you do (using WebLogic Time > API ). so far mine is working fine. > > Albert Pi > Corp IS System Delivery > 516-803-3762 > > > >>> Sunder Rajan <[EMAIL PROTECTED]> 09/19/02 01:25PM >>> > Hi Everyone, > I have a general question on J2EE scheduling. We run an application > that processes financial reports. We need to automate the report > generation. The idea is , The user will schedule certain reports > from a > web page. The reports will run based on whether certain data is > existent on a different domain. So lets say a user schedules Job A to > run as an automated report. Job A will and only run when certain data > is available in database X. So the current architecture is to > store the > different jobs in a table B, a startup class in weblogic will > check the > database X periodically(30 mins) to check and see if data is available > and update the job in table B(set data to true). A different startup > class will periodically check table B and see if data flag is true and > kick of a report by starting a new thread(A new thread is required > since the reports may run for 30-45 mins). Do you guys see any > pitfalls/drawbacks with this approach. Is there a better way of > solvingthis? > > Thanks, > Sunder > > ======================================================================== === > To unsubscribe, send email to [EMAIL PROTECTED] and include in > the body > of the message "signoff EJB-INTEREST". For general help, send > email to > [EMAIL PROTECTED] and include in the body of the message "help". > > fffffffffffffffffffffffff > To unsubscribe, send email to [EMAIL PROTECTED] and include in > the body > of the message "signoff EJB-INTEREST". For general help, send > email to > [EMAIL PROTECTED] and include in the body of the message "help". > > =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
