--- > What I had in mind was a node is a fixed size
> structure that contains a
> pointer (or reference) to table data which may be in
Yep. I pretty much agree with the priciple.
I built the BLinkTree to be a sorted map of elements
to longs. The longs can be references into just
about any
>Ok here is what I will do. I will put the code up to
sourceforge so you guys can check it out. Maybe you
will spot a way to make fine grain fast.
>
Gook idea. Some of us are busy with 1.7.0 release work but it would allow
others to comment.
>But I will change my assumptions to that only a si
Ok I posted my code at
https://sourceforge.net/tracker/index.php?func=detail&aid=547121&group_id=23316&atid=378133
Any questions or comments just email me
For some reason I fouled up the first time I posted
the code and can edit patch 547119. Could somebody
delete it.
=
Karl Meissne
see below
> In my view, the cases where fine-grained locks can
> make a difference are
> very few. But since you've been working with
The only place I can think of is a multi processor
system, a huge dataset and shared memory. This is
not our use case. HSQL seems to get used on single
proc
BTW: We also need on-the-fly indexing for TextTable support.
Bob
>From: "Fred Toussi" <[EMAIL PROTECTED]>
>To: "Karl Meissner" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
>Subject: Re: [Hsqldb-developers] fine grain threading
>Date: Sat, 20 Ap
Thanks Karl,
In my view, the cases where fine-grained locks can make a difference are
very few. But since you've been working with databases with very high insert
and update loads, you might know of a scenario that makes them desirable.
Please let us know.
Currently we are using 40 year old AVL
