Keeping a DCOM object alive from Java server on a REST invocation

Question

Hi,

I'm implementing a REST API for my Java server. One of the of the resources obtained through the API is actually creating a C++ DCOM object and reflecting its values. The Java to COM bridge I'm using is J-Integra.

The problem is that I need to keep that DCOM object alive for subsequent REST calls, but the object is alive just as long as its Java reference is - which is until the REST session expires at most.

How can I keep the DCOM object alive until I no longer needs it? The only thing I thought of till now was using an EJB which then will be the one to initiate the DCOM object and hold its reference. I'm not an expert on EJBs, but I think that a) its an overkill solution b) the EJB may be cached (passiviate?) by the server, losing the DCOM reference at that.

Any suggestions?

Thanks Inbar

Answer 1

How can I keep the DCOM object alive until I no longer needs it?

I guess that depends on what it means to no longer need the object. How do you know when you're done with it?

Are these DCOM instances applicable site-wide, or just for a specific user? If site-wide, is it possible for the resource that is receiving these requests to keep a reference to that object? If not, perhaps you need Yet Another Layer to manage those objects for you.

What framework are you using for REST?

---

Here's some more info: The DCOM object is executing a set of tasks async. So, the main call to it from the Java server returns immidietialy, while the DCOM object continues execution. Unfortuantley, it's quite an old object and i have no control over its implementation or interface - I can't change that. The DCOM object doesn't even have COM events. The only way to know if it is done or not, is to poll it using a specific method (getStatus). I don't want to poll it from my REST API implementation, as this will break the REST concept. I have no way to know in advance how long it will take for the DCOM object to run, so I can't keep the session alive that long.

So basically, you want to use a REST call to start an operation but don't care when it finishes or what its status is? If so, can you start a Thread that will start the DCOM operation, poll the status until the operation is deemed to be complete and then destroy the DCOM operation?

Answer 2

Hi Kevin,

Thanks for your answer.

Here's some more info: The DCOM object is executing a set of tasks async. So, the main call to it from the Java server returns immidietialy, while the DCOM object continues execution. Unfortuantley, it's quite an old object and i have no control over its implementation or interface - I can't change that. The DCOM object doesn't even have COM events. The only way to know if it is done or not, is to poll it using a specific method (getStatus). I don't want to poll it from my REST API implementation, as this will break the REST concept. I have no way to know in advance how long it will take for the DCOM object to run, so I can't keep the session alive that long.

The DCOM instance is applicable to a specific user, but I can skip the requirement to get its status in subsequent calls - I can settle for just making sure it completes the execution before its destructed. The user can check the execution results later in a different app, which views the same data.

Unfortunately, I can't see how a resource will keep that reference. As far as I understand, REST is not stateful, so the resource doesn't stay alive itslef. That's esseintaly my problem in the first place.

The REST framework I'm using was internally developed, but its very strict in adhering to the REST concept.

As for another layer - this is essentialy the direction I thought of, but I don't know enough about Java server side to be sure how to go about implementing this. Would EJBs be a good answer? If not, which other objects can be maintained out of session context in the Web\Java server side?

Regards, Inbar

Answer 3

Thanks, Kevin

The thread answer proved to work as expected.

Inbar

Answer 4

Place the component registered at COM+, and it stay alive. Check more info at this link.