From alemmens at xs4all.nl Wed May 20 15:32:25 2009 From: alemmens at xs4all.nl (Arthur Lemmens) Date: Wed, 20 May 2009 17:32:25 +0200 Subject: [rucksack-devel] Unexpected results from Rucksack (timing dependence?) In-Reply-To: References: Message-ID: Hi Klaus, > What I'm seeing, basically, is that the effect of calling the > tutorial's MAKE-CONTACT does not seem to show up consistently when > retrieving instances using RUCKSACK-MAP-CLASS. This is caused by a bug in Rucksack's MAKE-TRANSACTION-ID. This function should always return a fresh and unique ID, but sometimes it doesn't. I'll submit a fix for this Real Soon Now. Thanks again for the report, Arthur From alemmens at xs4all.nl Wed May 27 14:29:34 2009 From: alemmens at xs4all.nl (Arthur Lemmens) Date: Wed, 27 May 2009 16:29:34 +0200 Subject: [rucksack-devel] Unexpected results from Rucksack (timing dependence?) In-Reply-To: References: Message-ID: Hi, > This is caused by a bug in Rucksack's MAKE-TRANSACTION-ID. This function > should always return a fresh and unique ID, but sometimes it doesn't. I just committed a bug fix for this problem. Arthur From alemmens at xs4all.nl Wed May 27 15:54:51 2009 From: alemmens at xs4all.nl (Arthur Lemmens) Date: Wed, 27 May 2009 17:54:51 +0200 Subject: [rucksack-devel] [Rucksack] Ideas and Development In-Reply-To: <939D2C2D-1D48-4AEA-93B7-45808E2DA4BC@crispylogics.com> References: <939D2C2D-1D48-4AEA-93B7-45808E2DA4BC@crispylogics.com> Message-ID: [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