Re: Re: More questions

I've done a little caching in the POA version I've sent under separate 
cover as per your  (Sasa) request.  It seems to behave correctly, but I 
may not have thought of everything.  In addition, this version seems to 
work equally well with the built in Java ORB and with OpenORB.    I'm  
encouraged.

Dave

David Forslund wrote:

> Sasa Bojanic wrote:
>
>> Generally, maybe you are right, we could cache CORBA objects, and if 
>> something changes in the kernel, i.e. if some WfProcessMgr or
>> some WfProcess or WfActivity do not exist any more because XPDL was 
>> unloaded or process has been deleted, the CORBA server will get
>> an exception from the kernel.
>> However, than we have a problem with our approach with releasing 
>> CORBA objects when disconnect() method is called. Hence, if we have
>> caches, than several client applications could get the same CORBA 
>> object reference, and when one of them calls disconnect, other
>> applications will get an exception when they try to use the same 
>> reference.
>>
>> Regards,
>> Sasa.
>>  
>>
>
> As an example of what I'm thinking;.  In ExecutionAdminCORBA the call 
> to get_iterator_processmgr() returns a new CORBA object with reference 
> to the
> execAdmin.get_iterator_processmgr() in the kernel.   What would be 
> different about keeping that created CORBA reference so that it 
> returns the same CORBA object on the same method call from the 
> previously created ExecutionAdmin CORBA Object?  It is only visible to 
> that particular ExecutionAdmin object and thus there is no other 
> handle available.  It will be from the same user, etc.  If execAdmin 
> goes through a state change on each call to get_iterator_processmgr() 
> call, then I guess my suggestion is incorrect.    But if it is really 
> just returning a proxy handle to an existing processmgr,  there would 
> seem to be no harm in locally caching the reference.   There are 
> numerous examples of this but they do depend on whether the underlying 
> server state is changing or not from the call.   It is difficult for 
> me to wade through all the code to find out.
>
> Dave
>
>>

--
You receive this message as a subscriber of the [email protected] mailing list.
To unsubscribe: mailto:[email protected]
For general help: mailto:[email protected]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws