Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: 209.147.113.130 is neither permitted
 nor denied by domain of mmcgrady@topiatechnology.com)
References: <4CF89BD3.3030103@acm.org> <4CF909A0.5070409@wonderly.org>
 <4D056E41.7020102@acm.org> <4D057B73.3090905@zeus.net.au>
 <4D05BA22.4000002@acm.org> <4D06672A.10203@wonderly.org>
 <4D066FA2.8050207@wonderly.org> <4D069D21.5070908@zeus.net.au>
 <4D06BA8D.4040602@simulexinc.com> <4D06C523.5000006@acm.org>
 <5E44AB11-EC78-476E-8A6D-C9AEBEFCA3D2@topiatechnology.com>
 <4D079D60.4070607@wonderly.org> <4D07E442.5040908@acm.org>
 <39AED645-40CC-4314-9956-25BE1325B2F5@topiatechnology.com>
 <4D07E9D4.2080106@acm.org>
 <B9558304-8B77-4CFB-B23B-73A29D89B65F@topiatechnology.com>
 <4D0856B2.1070107@acm.org>
 <DD8D109E-0158-438A-ADB0-F8180C8B01A8@topiatechnology.com>
 <4D0A1A61.2020805@acm.org> <4D0A1D90.2000900@qcg.nl>
 <4D0B8903.8090704@wonderly.org>
In-Reply-To: <4D0B8903.8090704@wonderly.org>
Mime-Version: 1.0 (iPhone Mail 8C148a)
Content-Type: text/plain;
	charset=us-ascii
Message-Id: <38456AEA-D4D9-434B-9027-070731755D97@topiatechnology.com>
Content-Transfer-Encoding: quoted-printable
Cc: "river-dev@incubator.apache.org" <river-dev@incubator.apache.org>,
 Sim IJskes - QCG <sim@qcg.nl>
From: Mike McGrady <mmcgrady@topiatechnology.com>
Subject: Re: datastructure classes
Date: Fri, 17 Dec 2010 08:20:41 -0800
To: "river-dev@incubator.apache.org" <river-dev@incubator.apache.org>

I concur.

Sent from my iPhone

Michael McGrady
Principal investigator AF081_028 SBIR
Chief Architect
Topia Technology, Inc
Work 1.253.572.9712
Cel 1.253.720.3365

On Dec 17, 2010, at 8:00 AM, Gregg Wonderly <gregg@wonderly.org> wrote:

> On 12/16/2010 8:09 AM, Sim IJskes - QCG wrote:
>> On 16-12-10 14:55, Patricia Shanahan wrote:
>>>> However, we should be able to do, say, hundreds of millions of
>>>> transactions in a day in real-time critical systems such as the FAA
>>>> or the stock market with data affinity and integrity and all the
>>>> other "ilities". If Outrigger cannot do this, it is of no interest
>>>> to us.
>>>=20
>>> The current record for a relational database doing simple transactions
>>> is 30 million transactions per minute (Oracle/SPARC TPC-C). Your mileage=

>>> may vary, but there is no inherent limit on relational database scaling
>>> that puts a few hundred thousand transactions per minute out of reach.
>>=20
>> Apart from that, it would be very interesting to see how a COTS DB backed=

>> javaspace whould behave in practice. And it could be the first step into
>> producing alternative persistence mechanisms. In the early stage it would=
 be
>> comfortable to know we don't have to prove the correctness of a cots-db. I=
n a
>> later stage we can always look at lifting the transaction based blockstor=
age
>> layer from derby or another java based db for instance.
>=20
> One of the primary issues with bandwidth through any system is latency.  W=
hile multiprocessor/multi-core and distributed computing can provide huge ba=
ndwidth possibilities, the underlying issue is per transaction latency.
>=20
> If you look simply, at the JDBC model for example, the act of converting t=
he JDBC activities to network traffic and back (marshal/unmarshal) is one of=
 the primary "time consuming operations".  When you add onto that other over=
head associated with how each database authenticates and manages its "networ=
k" traffic.  I have no exact numbers to demonstrate this, but it is somethin=
g which I have very long experience dealing with, over the years, with my br=
oker (built before JMS existed) and catching up 100's of thousands of transa=
ctions into databases which have gone down for maintenance.
>=20
> JDBC only allows one transaction per connection, so you have context overh=
ead involved there.  With each transaction coming across a separate TNS-List=
ener process in oracle, you have OS context switching issues that inject lat=
ency.
>=20
> Overall, the bandwidth can be very large, but the per transaction latency i=
s probably the biggest reason that SQL databases are not always the best cho=
ice for some types of performance needs.
>=20
> Gregg Wonderly