I know of at least one company which uses Outrigger specifically because of it's fortuitous FIFO behaviour. I'm trying to encourage them to move from the Jini 2.1 code to the River release and losing the FIFO-ness might be an issue for them.
And yes I know, the spec doesn't specify FIFO, like I said, they needed a FIFO space, and Outrigger "just happened" to behave like that. On Sat, Dec 18, 2010 at 12:03 AM, Patricia Shanahan <p...@acm.org> wrote: > On 12/17/2010 8:00 AM, Gregg Wonderly wrote: > ... >> >> One of the primary issues with bandwidth through any system is latency. >> While multiprocessor/multi-core and distributed computing can provide >> huge bandwidth possibilities, the underlying issue is per transaction >> latency. >> >> If you look simply, at the JDBC model for example, the act of converting >> the JDBC activities to network traffic and back (marshal/unmarshal) is >> one of the primary "time consuming operations". When you add onto that >> other overhead associated with how each database authenticates and >> manages its "network" traffic. I have no exact numbers to demonstrate >> this, but it is something which I have very long experience dealing >> with, over the years, with my broker (built before JMS existed) and >> catching up 100's of thousands of transactions into databases which have >> gone down for maintenance. >> >> JDBC only allows one transaction per connection, so you have context >> overhead involved there. With each transaction coming across a separate >> TNS-Listener process in oracle, you have OS context switching issues >> that inject latency. >> >> Overall, the bandwidth can be very large, but the per transaction >> latency is probably the biggest reason that SQL databases are not always >> the best choice for some types of performance needs. > > Thanks. It's very useful to know specific gotchas with a given > implementation strategy. > > Patricia >
