Ok, I just checked in a fix that should work for SBCL, CMU, LispWorks
and MCL and that I've done a preliminary test of under SBCL/Mac OS
I also added a simple adaptation algorithm so that the system slowly
moves towards the average object collection size. It will naturally
tune to the thread usag
Oops - I forgot about that hack. In order to make serialization thread
safe I need to use locks which are non-standard. I'll hack something
for SBCL in minute or two.
If you want to manually controll transaction you can use the following
protocol:
(start-ele-transaction)
(transaction-commit)
(t
For the record, the current measure of a successful body within
(with-transaction ()) is an ordinary exit. _ANY_ non-local exit such as
throw, error, etc as well as goto labels, or (return-from )
all result in aborts. More technically the test is written as:
(with-transaction ()
)
=>
(unw
Ah, this was a false alarm. Vladimir, the latest HEAD should fix the
problems you reported.
As mentioned in my last note this was actually a bug I introduced in
fixing some memory problems that crop up when using add-index on a large
primary index with the populate option (it used to exhaust BDB'
Vladimir,
I applied your changes, cleaned up some other changes for a check in. I
found the same errors as you on Mac OS using Allegro. Digging deeper
into this it appears there are genuine issues cropping up in these two
tests.
It appears that a pcursor-next operation returns nil instead of t
Hello,
I was working against HEAD circa late last week. I guess I should have
realized there might be some broken code in the repository. :) The
same tests passed before and after, so at least it doesn't look like I
broke anything new.
Since only the flag constants changed as far as the interfac
Way to go! Did you test against the current HEAD or the 0.6.0 release
branch? All tests passed on 0.6.0 so if you are working from that
release you should be worried, but it's possible that not all tests pass
the current HEAD. Also, did they pass before and after your fix?
In any event, I presu
Wow! Thanks for this patch. I will try to integrate it into the repository early next week.
"Should you be worried?" -- If all but those two test pass, you probably have a usable
system for most purposes, and it will take you a long time to trip over whatever bugs
causes those two failure
Daniel (and others),
I'm subjecting the BDB backend to extremely high throughput loads on a
daily basis and it's the first backend I test when I check in changes.
Between Robert and I we cover a large % of the uses of Elephant on Win32
and Mac OS. I'm in the middle of a demanding project so I ha
On Sun, 2006-08-13 at 23:27 -0400, Daniel Salama wrote:
Robert/team,
I know I've discussed this in the past, but somehow, your comment has awaken my concern as to the future of Elephant and Sleepycat. I know you've mentioned that you are using Elephant mainly (or only) for the relation
Robert/team,I know I've discussed this in the past, but somehow, your comment has awaken my concern as to the future of Elephant and Sleepycat. I know you've mentioned that you are using Elephant mainly (or only) for the relational backend. However, being that the BDB backend is about 5 times faste
On Sun, 2006-08-13 at 02:27 -0400, Daniel Salama wrote:
Being that BDB is on version 4.4.20 and there seem to be some
important fixes since the 4.3 version, does Elephant support this
version? Is there any plans to support it?
Thanks,
Daniel
I don't have any plans to work on this in t
12 matches
Mail list logo
