Re: Invoking methods from multiple threads - connection policy

[Toralf Lund <toralf lund pgs com>]

Frank Rehberger wrote:
> Toralf,
>
> if I remember correctly, there are at least these two options:
> ORBIT_THREAD_HINT_PER_REQUEST
> ORBIT_THREAD_HINT_PER_CONNECTION
>
> I would recommend the second one (per-connection), if it comes to  
> near-real-time processing, to avoid priority inversion.
>   
It seems to me that if I use this in conjunction with a multi-threaded 
client, I essentially get single-threaded behaviour for CORBA calls 
(there will only be one thread on the server-side) if the CORBA object 
is shared between the threads on the client side. That's if the client 
is implemented the ORBit2 way, i.e. all operations on an object is sent 
across the same socket or whatever, regardless of which thread they come 
from. This is why some other ORBs will set up separate links for 
separate threads.

Or am I missing something?

- Toralf
> Quoting "Toralf Lund" <toralf lund pgs com>:
>
>   
> > Frank Rehberger wrote:
> >     
> > > Quoting "Toralf Lund" <toralf lund pgs com>:
> > >
> > >
> > >       
> > > > Am I correct in assuming that when I invoke CORBA methods (on the   
> > > > same CORBA_Object) from different threads, they will by default   
> > > > share the GIOP/linc/socket connection - i.e. data from different   
> > > > threads is multiplexed? I know that some other ORBs will   
> > > > (optionally) set up one connection per thread - see for instance   
> > > > http://omniorb.sourceforge.net/omni40/omniORB/omniORB008.html   
> > > > (section 8.3.) Is there any way I can configure ORBit2 to do this?
> > > >
> > > >         
> > > You are asking for client side option: sorry, no
> > >
> > >       
> > That's what I thought, after reading some of the code... It's too  
> > bad, in a way, but at least I know for sure now that it can't be done.
> >
> > Fortunately, we also have the option of adapting the server we're  
> > connecting to, which is incidentally the one set up using omniORB  
> > (*without* "demultiplexing" support right now.)
> >
> > By the way, does this mean that ORBIT_THREAD_HINT_PER_REQUEST is the  
> > only option if I want an ORBit2 server to execute requests in  
> > different threads when they come from different client-side threads  
> > that share the CORBA object? Or does the system have some other way  
> > to distinguish requests from different client threads?
> >
> > - Toralf
> >
> >
> >
> > This e-mail, including any attachments and response string, may  
> > contain proprietary information which is confidential and may be  
> > legally privileged. It is for the intended recipient only. If you  
> > are not the intended recipient or transmission error has misdirected  
> > this e-mail, please notify the author by return e-mail and delete  
> > this message and any attachment immediately. If you are not the  
> > intended recipient you must not use, disclose, distribute, forward,  
> > copy, print or rely on this e-mail in any way except as permitted by  
> > the author.
> > _______________________________________________
> > orbit-list mailing list
> > orbit-list gnome org
> > http://mail.gnome.org/mailman/listinfo/orbit-list
> >
> >     
>
>
> _______________________________________________
> orbit-list mailing list
> orbit-list gnome org
> http://mail.gnome.org/mailman/listinfo/orbit-list
>   


This e-mail, including any attachments and response string, may contain proprietary information which is confidential and may be legally privileged. It is for the intended recipient only. If you are not the intended recipient or transmission error has misdirected this e-mail, please notify the author by return e-mail and delete this message and any attachment immediately. If you are not the intended recipient you must not use, disclose, distribute, forward, copy, print or rely on this e-mail in any way except as permitted by the author.