[Topaz-dev] Mulgara Performance Woes

[Life is hard, and then you die]

[warning: the rest here is _not_ applicable to our current mulgara
usage which is via soap, but to the future usage which is via RMI]

On Sat, Mar 01, 2008 at 09:51:46PM +1000, Andrae Muys wrote:
> 
> On 01/03/2008, at 3:45 AM, Russell Uman wrote:
> 
> >
> >> We need some idea of A) how long transactions are being kept
> >> open,
> >
> > because certain things take a long time to serve (search, feeds,  
> > etc.).
> > because once the pub-app times out its connection to mulgara, mulgara
> > keeps the transaction open for a long time, hopefully waiting.
> 
> There's been a pending feature request to provide some sort of  
> keepalive on session connections for quite a while now, maybe this is  
> the impetus needed to push it to the front of the queue.

Hmm, I thought RMI controlled connections? Is there a way to manage
them? Or are you talking about having mulgara issue some sort no-op on
the client side periodically in hopes of keeping the underlying
rmi/tcp connection open? Do you know, does Sun's RMI implementation
multiplex different requests over a single tcp connection, or does it
use a separate connection for each request in progress?

> On the other hand, if we used a two-level lock for the write-lock we  
> could support a preemptive close operation on session - allowing you  
> to clear the queue as app's timeout.

Not sure if that will buy much: if a session is waiting on the
write-lock can't you already go and close() it from another thread?
(Ok, I believe it'll still acquire the lock but then it'll quickly
notice the session has been closed and release it again - at least
that was my understanding).


  Cheers,

  Ronald