[rucksack-devel] [Rucksack] Ideas and Development

[Arthur Lemmens]

[CC'ing the rucksack-devel mailing list.]

Hi Jochen,

Sorry for the slow reply.  I don't have much time to spend on Rucksack
these days, and fixing the bug reported by Klaus Harbo was on the top
of my list.  But that should be fixed now.

> I'm working with and on rucksack since quite some time.

That's good to hear, thanks.

> WITH-RUCKSACK/WITH-TRANSACTION-Sandwich on DEFCLASS
> I've some message from August of '08 were you state that you already
> have some code to make it unnecessary to wrap DEFCLASS in the "WITH-
> RUCKSACK/WITH-TRANSACTION-Sandwich". AFAIU you didn't yet checkin
> something do you?

Yes, I have some code and no, I didn't check it in.  I'll try to find it
and check it in (if I still like the code that I wrote at the time).


> (defmethod rucksack-register-class ((rucksack rucksack) (class
> persistent-class))
>    (rs::maybe-update-schemas
>       (rs::schema-table (rucksack-cache rucksack))
>       class)
>    (rs::update-indexes class))
>
> is enough to register a persistent-class defined without the sandwich
> with an empty rucksack. Is that enough?

I think it's similar to my solution.  But I also added a special variable
that keeps tracks of the persistent classes that were defined while there
was no open rucksack.  Then, when a rucksack is opened, the persistent
classes are 'registered' in the rucksack.  Of course this only works well
when you're working with one rucksack at a time.  But that's the most
common use case, I suppose.

> If I undersand it right, the current transaction infrastructure only
> supports one transaction at a time (controlled by a lock on
> TRANSACTION-START-1 and TRANSACTION-COMMIT/ROLLBACK-1 for SERIAL-
> TRANSACTION-RUCKSACK). There seems to be some code though, which
> assumes that multiple transactions can be side by side. Can you give
> me some direction on what is actually missing to make multiple open
> transactions possible?

That's a difficult question and I haven't thought about this kind of
stuff for a long time.  I think there is no single right answer to this
question, but my original idea was that it should be possible to define
and implement a few different strategies for parallel transactions.

Probably the most important thing to work on for multiple open transactions
is to get some kind of parallel access to the btrees that are used for the
slot and class indexes.  For example: if the multiple open transactions
access different part of the btrees, I think it would not be necessary to
serialize them.  So you could try to move the locks to lower levels of the
btrees while you're accessing them.  The 'lower' the lock, the lower the
probability that a transaction will have to wait for the owner of that
lock.

Leonid Novikov also posted some code for multiple transactions on the
mailing list last year.  If you can't find it, let me know and I'll
try to dig it up.

All the best,

Arthur Lemmens