Multiple readers to non-transactional index?
hbf
First of all, thanks a lot for open-sourcing HawtDB! This project
looks great and fills a need!
I have a few questions:
1. First of all, the website says
"BTree: Maintain keys in sorted order and support sorted iteration.
Hash: Keys are not sorted. Can perform better than hash indexes."
I suppose you mean "... than BTree indexes", right?
2. HashIndexFactory is for non-transactional indexes and cannot be
used with transactional indexes, correct?
3. If I use a non-transactional setup with a HashIndexFactory, can
multiple threads access the index read-only? In other words, if I were
to use read/write locks on top of a HawtDB index to guarantee that at
any time EITHER at most one writer OR only readers are accessing the
index, is this guaranteed to work?
4. In the non-transactional setup, is there a Durability (as the D in
ACID) guarantee: If you kill the process, will the index survive,
i.e., be recovered? (This has been answered in the post
http://groups.google.com/group/hawtdb/browse_thread/thread/7b2fea288348076
for the case of the transactional setup.)
Many thanks for any answers and pointers.
Best,
Kaspar
P.S. The sentence "Perhaps your just using the index to page out of
memory temporary values that can be discarded on restart" on the
website might be slightly misleading. IIUC, non-transactional indexes
ARE persistent – the reader might think no. Maybe just drop the part
"that can be discarded on restart"?
Hiram Chirino
> Hi,
>
> First of all, thanks a lot for open-sourcing HawtDB! This project
> looks great and fills a need!
>
> I have a few questions:
>
> 1. First of all, the website says
>
> "BTree: Maintain keys in sorted order and support sorted iteration.
> Hash: Keys are not sorted. Can perform better than hash indexes."
>
> I suppose you mean "... than BTree indexes", right?
>
ah correct.
> 2. HashIndexFactory is for non-transactional indexes and cannot be
> used with transactional indexes, correct?
>
No the index factories can be mixed and matched with the page files
implementations. So yes hash indexes can be used with either
transaction or non transaction page files.
> 3. If I use a non-transactional setup with a HashIndexFactory, can
> multiple threads access the index read-only? In other words, if I were
> to use read/write locks on top of a HawtDB index to guarantee that at
> any time EITHER at most one writer OR only readers are accessing the
> index, is this guaranteed to work?
>
yes, that will work.
> 4. In the non-transactional setup, is there a Durability (as the D in
> ACID) guarantee: If you kill the process, will the index survive,
> i.e., be recovered? (This has been answered in the post
> http://groups.google.com/group/hawtdb/browse_thread/thread/7b2fea288348076
> for the case of the transactional setup.)
>
No, the non transaction page file itself can't guarantee it. When the
process gets killed an the page file could be left in a state where a
partial update was performed and so at least one page is corrupted and
or you could have several page writes that are applied out of order
with the previous ones not having been stored. Since the
non-transaction pages file does no recovery logging of the the updates
applied, it can recover from those kinds of failures.
> Many thanks for any answers and pointers.
>
> Best,
> Kaspar
>
> P.S. The sentence "Perhaps your just using the index to page out of
> memory temporary values that can be discarded on restart" on the
> website might be slightly misleading. IIUC, non-transactional indexes
> ARE persistent – the reader might think no. Maybe just drop the part
> "that can be discarded on restart"?
Thanks, good pointer.
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://fusesource.com/
hbf
helped!
Kaspar
On Jul 29, 5:17 am, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > Hi,
>
> > First of all, thanks a lot for open-sourcing HawtDB! This project
> > looks great and fills a need!
>
> > I have a few questions:
>
> > 1. First of all, the website says
>
> > "BTree: Maintain keys in sorted order and support sorted iteration.
> > Hash: Keys are not sorted. Can perform better than hash indexes."
>
> > I suppose you mean "... than BTree indexes", right?
>
> ah correct.
>
> > 2. HashIndexFactory is for non-transactional indexes and cannot be
> > used with transactional indexes, correct?
>
> No the index factories can be mixed and matched with the page files
> implementations. So yes hash indexes can be used with either
> transaction or non transaction page files.
>
> > 3. If I use a non-transactional setup with a HashIndexFactory, can
> > multiple threads access the index read-only? In other words, if I were
> > to use read/write locks on top of a HawtDB index to guarantee that at
> > any time EITHER at most one writer OR only readers are accessing the
> > index, is this guaranteed to work?
>
> yes, that will work.
>
> > 4. In the non-transactional setup, is there a Durability (as the D in
> > ACID) guarantee: If you kill the process, will the index survive,
> > i.e., be recovered? (This has been answered in the post