[omniORB] Re: omniOTS Scalability

[Luke Deller]

Sure, here are our changes (patch attached), which includes:

- a new TimeOutControl which creates a new thread only if a timeout
  occurs [ mostly by syang at xplantechnology.com ]

- missing call to self._coord.synchronize in Terminator.commit

- ensuring that a transaction ID is globally unique by including
  hostIP, pid and module start time in the ID

- fix the transaction equality and relationship testing operations
  in Coordinator.py (note that we can't compare hash values nor
  CORBA references for equality)

Feedback welcome.

Regards,
Luke.

On Mon, 2005-03-14 at 11:19 -0800, Scott Robertson wrote:
> We're aware of that particular issue, but in the two years of production
> it hasn't bitten us yet.
> 
> I've started work awhile ago on a better way to rollback transactions in
> TransactionServer/TransactionReaper.py but it hasn't been a priority for
> us yet. 
> 
> Would you be willing to share you changes?
> 
> On Mon, 2005-03-14 at 11:30 +1100, Luke Deller wrote:
> 
> > We also noticed a scalability issue with the transaction server: a new
> > thread is created for each transaction, to wait for the transaction
> > timeout.  This allows only a few hundred concurrent transactions due to
> > system limits on the number of threads.  We have adjusted this code to
> > use a single thread for waiting for timeouts.  Only when a timeout
> > actually occurs does it start a new thread to perform the transaction
> > rollback.  I'm not sure if this is still an issue with your new version
> > though.
> > 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: omniOTS-timeoutctrl.patch
Type: text/x-patch
Size: 22610 bytes
Desc: not available
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20050322/12015a52/omniOTS-timeoutctrl-0001.bin