Re: Re: More questions

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

>----- Original Message -----
>From: "David Forslund" <[email protected]>
>To: <[email protected]>
>Sent: Monday, June 27, 2005 9:55 PM
>Subject: Re: [shark] Re: More questions
>
>
>  
>
>>Sasa Bojanic wrote:
>>
>>    
>>
>>>Hi Dave,
>>>
>>>I agree, we should prevent nulls to be send over CORBA.
>>>
>>>
>>>      
>>>
>>I will try to deal with some as I encounter them, but it isn't always
>>clear what your intent is.  In the case I mentioned, it is pretty clear
>>because you check for a null returned in a String over CORBA.  However,
>>this will never happen with CORBA.  It always throws an exception on
>>sending nulls.
>>
>>    
>>
>>>Is there any particular problem with getting new objects for xxxIteratorExpressionBuilders?
>>>As you know, this is the principal of CORBA shark to always create new CORBA object for every client request. If we would
>>>      
>>>
>introduce
>  
>
>>>caches of CORBA objects, we could have problems if using several server VMs.
>>>
>>>
>>>      
>>>
>>I don't understand why this is a problem if the objects are grouped
>>together.   For example, if you have an object and then want its
>>manager, it should be easy to get it without having to create another
>>object, or if you create a iterator mapping an iterator in the kernel,
>>why not keep using it?   When you make a new one, when does the old one
>>get destroyed?  It might be possible to use the POA process to manage
>>this much more efficiently.  I don't understand why multiple VMs is an
>>issue.
>>
>>Thanks,
>>
>>Dave
>>
>>    
>>
>>>Regards,
>>>Sasa.
>>>
>>>----- Original Message -----
>>>From: "David Forslund" <[email protected]>
>>>To: <[email protected]>
>>>Sent: Monday, June 27, 2005 7:13 AM
>>>Subject: [shark] Re: More questions
>>>
>>>
>>>
>>>
>>>      
>>>
>>>>I notice in the AdminMisc.getBlockActivityId() method it can return a
>>>>null string which throws an exception on the client.   I gather you use
>>>>this to find out that the activity is not in the current process (at
>>>>least according to the  inline comments).  Sending the null over CORBA
>>>>causes an exception.  This is a bad idea to have CORBA throw an
>>>>exception to decide to proceed to the next item.  There must be a better
>>>>way.   I'm looking for any CORBA error to debug my POA implementation
>>>>and this is causing me confusion, but basing logic decisions on
>>>>Exceptions is generally not a good idea, in my opinion.
>>>>
>>>>The other question I have is that I see the
>>>>getProcessMgrIteratorExpressionBuilder() method called numerous times in
>>>>the ExpressionBuilderMgrCORBA class.  Each time it returns a new
>>>>ProcessMgrIteratorExpressionBuilder, but isn't this always the same
>>>>object on the server?   Perhaps I don't understand what is happening
>>>>here, but it seems to me to making a lot of objects (albeit only
>>>>wrappers) for the same underlying object.
>>>>
>>>>I am converging, but these little rabbit trails are distracting.
>>>>
>>>>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