[omniORB] optimizing reference counting

[bjorn rohde jensen]

Hi Kevin,

 Unless these few instance objects are really heavy weight,
i don't think, you would gain much from implementing distributed
reference counting. Secondly, it might be prudent to worry
about reference count optimizations, until you have made it
work reliably enough. Maybe that will also be fast enough.
You need to focus on the system requirements for fault
tolerance, that will be the nasty part.
 I think, you will need to add application logic on both
server and client side for the distributed reference
counting to work properly, so maybe it would be simpler to
build your own protocol on top of CORBA?
 I still don't understand, why you want to do this sort
of thing. A default servant using an evictor pattern to
send objects to persistent storage (and possibly later into
oblivion...) really ought to be good enough. Persistent
storage could even be provided be a remote application.
 Are you operating under real time requirements on an
embedded platform or something?

Yours sincerely,

Bjorn

Kevin Wooten wrote:
> 
> After previous discussion's on the list I decided to use reference counting, but only for a select number of interface's that have a low instance count. My next question is if anyone can think of a way to optimize the speed of reference counting for distributed objects. For example, DCOM (I know, you all cringe at it's use as an example) clients maintain a reference on object proxies, and when those proxies are destroyed a release call is forwarded to the server, but no other ref. count calls are forwarded. I know CORBA maintains a proxy much the same way, I also know it is reference counted, is there any way to intercept the destruction of this object, so I could send a release call myself. I realize this is all very non-standard, and any solutions will probably tie the application directly to omniORB, but that is fine. Maybe, if there is a way to store some extra data per object reference, I could use interceptors to intercept all calls to addReference, releaseReference, and only
> send the releaseReference call when the reference is zero. Any suggestions?
> 
> Kevin Wooten
> iTRACS Corporation
> email: kwooten@itracs.com
> phone: 480-557-8000 ext. 132
>