> Hmmm...I believe that only the first to connect should attempt recovery.
I'm not so sure about that (in fact I think DB_REGISTER is only there
so you can specify DB_RECOVER for every process), but it doesn't really
matter for me as long as it works. The only solution for me therefore
is having
Hmmm...I believe that only the first to connect should attempt recovery.
Much of these issues are BDB restrictions that one has to live with if
you want to do more than the basic thing with them. It would be
worthwhile for you to read up on BDB if you want to do the multi-
process implement
> I just pushed a patch that should automatically manage two processes
> connecting to the same environment. You typically have to coordinate
> who is the master user and who is the slave so that you don't try to
> recover an environment that is already in use by another process.
> This causes th
> I don't fully understand all the BDB particulars here, but I'm short
> on time to fix these things. Let me know if this works for you. The
> short story is that BDB is unlikely to 'just work' for a real system
> using multiple processes. You have to run deadlock detection
> (probably in a par
I just pushed a patch that should automatically manage two processes
connecting to the same environment. You typically have to coordinate
who is the master user and who is the slave so that you don't try to
recover an environment that is already in use by another process.
This causes that
> To isolate the problem, can you verify the base case, connect two
> images to a fresh db?
Here's one for SQLite:
(asdf:oos 'asdf:load-op 'elephant)
(defpackage #:ele-test (:use :cl :elephant))
(in-package :ele-test)
(defpclass myclass ()
((testslot :accessor testslot :initarg testslot :i
> To isolate the problem, can you verify the base case, connect two
> images to a fresh db?
For BDB:
(asdf:oos 'asdf:load-op 'elephant)
(defpackage #:ele-test (:use :cl :elephant))
(in-package :ele-test)
(defpclass myclass ()
((testslot :accessor testslot :initarg testslot :index t)))
(op
> Why don't you send over stack traces and a more in-depth description
> of your setup.
Here's the BDB case.
Underlying setup is the same as in the SQLite scenario. Backtrace inline
at the bottom of this message (irrelevant parts cut).
I have a game engine and an administration backend, which a
> Why don't you send over stack traces and a more in-depth description
> of your setup.
Here's the SQLite story.
I'm using SQLite3 version 3.5.6 (apparently compiled with thread safety),
CLSQL 4.0.1, SBCL 1.0.14 and the latest Elephant on an ext3 file system,
kernel 2.6.24.
The error occurs on
I just opened a fresh DB from both an Allegro image and an SBCL image
with no problems, set some data in one and read it from the other.
This fails for you? I believe other people are using multiple images
on multi-processor machines without incident so this may be a
configuration or envi
I just got this:
While accessing database #
with expression "UPDATE KEYVALUE SET KEY =
'DysNCQYAAABQT1RJT04JBgAAAE1ZU1RJQw==',CLCTN_ID = 28,VALUE =
'DQkBVAkLAAA
AQ09NTU9OLUxJU1A=' WHERE ((CLCTN_ID = 28) AND (KEY =
'DysNCQYAAABQT1RJT04JBgAAAE1ZU1RJQw=='))":
Error 5 / database is l
11 matches
Mail list logo
