Re: application design question

From: Igor Racic <igor.racic_at_gmail.com>
Date: Tue, 28 Jun 2011 10:23:15 +0200
Message-ID: <BANLkTingdNh9MFRCPyK+6R7WX07ARFy6AA_at_mail.gmail.com>



Hi,

One way can be, as you said, to run asyncrously using scheduler / dbms_job. And then to find out result, you can either pool after X seconds or try to use some other mechanism ( like dbms_alert ).

Another approach, which would be simpler to implement and manage is to still do as you do it right now, but from background thread. How, depends of type of your GUI, try to talk with your GUI guys. For example, Swing has SwingUtilities.invokeLater(...), SWT has something like Display.getCurrent().asyncExec(...) etc
This way, your users are not stuck with some unresponsive inteface (gray / undefined screen).
User can have some status in status bar with progress info, can do anything else inside application and be informed when job is done.

Of course, you can do some variation of these approaches (and maybe include some 3rd party that would do it instead of server or client).

There is also one another Oracle technology (Database change notification) that may or may not be useful in your case...

Regards,
Igor

2011/6/17 Michael Moore <michaeljmoore_at_gmail.com>

> Currently we have a Java GUI that invokes a pl/sql package procedure (A)
> which does a lot of stuff and then returns control to the GUI. The trouble
> is, it's taking too long. The 'stuff' it does is more suitable to a batch
> job.
>
> My proposed solution is for the GUI to invoke procedure (B) which will then
> use DBMS_SCHEDULER to immediately invoke procedure (A). Procedure (B) would
> then, of course, immediately return control to the GUI.
>
> The Java GUI functionality would be expanded to be able to monitor
> currently running jobs and all jobs ( of this type) for say, the last month.
> The user should be able to see his job, when it ran, success/fail, and any
> error messages that might have been raised.
>
> What is the best way to go about this. No doubt this wheel has already been
> invented many times. Is there an existing code framework that I can leverage
> so that we don't need to write this from scratch?
>
> TIA,
> Regards,
> Mike
>

--
http://www.freelists.org/webpage/oracle-l
Received on Tue Jun 28 2011 - 03:23:15 CDT

Original text of this message