Disconnect and reconnect to an EJB

[AlistairMonkeyFinger]

Hi all,

i want to do the following but i'm not sure if it's possible. I want a client app to create a instance of an EJB on the server, give it some parameters then disconnect (shutdown) leaving the EJB to go away and process a large amount of data. Throughout the duration of the processing i want the client to be able to connect back to the bean to monitor progress. So my questions are...

Is this possible using EJB's ?

Which EJB do i use ?

How does the client know which bean to connect back to monitor its progress ? (assuming mutliple clients could set off processing).

Or is there another way to do it - maybe the client doesn'y connect to the same bean they dosconnected from, but to any bean that can monitor the progress of a task on a different (known) thread ?

Any thoughts would be useful
TIA



Alistair

 

[prosper]

I learn some knowledge on ejb by books.
I think your task can be a batch job, so it should be started by only one person. But if the job is running, the progess can by viewed by multiuser and the job can be cancelled by multiuser with high access right.

After the ejb has processed 1000 records, it updates database that 1000 more records have been processed. It checks a database record if the job is ordered to be cancelleed by person with high access right. If yes, rollbacked.
Otherwise, the ejb continue to do the job...
If the job is finished and no order is given to cancelled the job, commit will be called.

I think sessionbean is ok for a large batch job.
Correct the points if I am wrong.

 

[hologram]

IF you want to do it with EJB, have a look at "Message-Driven Beans" to see if they might be helpfull.

See the EJB articles at :

http://www.theserverside.com/articles/index.tss

 

[dbleyl]

hologram is right. You may even consider just using JMS.
Essentially:

1. server tells JMS provider it would like to listen for
'process request' messages.

2. client tells provider it would like to listen for
'completed' messages.

3. client publishes or queues 'request messages'

4. server gets message, does work, posts 'completed message'

5. client receives 'completed message', work done.

You can specify parameters and ids and such in the header or message body. There are many ways to set this up, and a lot of options regarding guaranteed delivery etc.