I thought about using one process, but there doesn't seem a way to do this in
Weblocks.
I'll try Ian's sugestion.
Yarek
-Original Message-
From: Robert Synnott
Sent: Thursday, December 11, 2008 5:52 PM
To: Elephant bugs and development
Subject: Re: [elephant-devel] Is it safe to use
2008/12/11 Yarek Kowalik :
> I've read section 4.13 in the doc, and it appears that it's possible to use
> two processes. However, when I launch two processes reading the same
> database, the first process trows errors (see trace below).
>
> Something is messing up the access/confing for the first
Take a peek at the issues around sharing a DB environment in the BDB
docs and look at the open-controller args and see where you get. I
won't be able to look into this for a few days but can answer the
occasional question (probably best to e-mail me offline of the mailing
list until we res
Multiple lisp processes (in a shared memory environment) should be
safe, but I'm not sure if it's tested (anyone here done this?).
I believe they have to use the same BDB environment, so you may need
to do some checking on the proper open-store arguments to join vs.
create an environment. S
I've read section 4.13 in the doc, and it appears that it's possible to use
two processes. However, when I launch two processes reading the same
database, the first process trows errors (see trace below).
Something is messing up the access/confing for the first process.
I was hoping I would not
I'm trying to access BDB 4.5 backed elephant store (elephant-unstable) from
two different lisp processes using the elephant package. Is this a safe
thing to do?
Yarek
___
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/ma
Yep, store gets opened on application start, before session-init is called.
Also, moving init-dummy to open-store :after pushes the problem further,
then I get a BDB-DB-ERROR when calling
(elephant::get-db-schemas (weblocks-elephant::elephant-controller
*my-elephant-store*) 'product-item)
- th
I'm guessing it is not... as that's what's causing some of my data
problems I thought BDBs can handle multi-process access.
Yarek
On Thu, Dec 11, 2008 at 2:23 PM, Yarek Kowalik wrote:
> I'm trying to access BDB 4.5 backed elephant store (elephant-unstable) from
> two different lisp processe
BDB 4.5 for back-end.
I'm using elephant-unstable, pulled last week.
I'm elephant this via Weblocks, so I'm assuming the store is open by the
time the init-session for Weblocks app is called. Maybe I should check on
that - it's possible that the store is not in fully open state?
Yarek
On Thu, D
Which version of elephant are you using?
Which backend are you using? If BDB, which version?
I presume *store-controller* open and reachable from the package you
are in?
Looks like the elephant store isn't in the proper state (e.g. was
closed and *store-controller* was not zeroed out).
On D
I've converted my weblocks app to use elephant. One of the first things I
do is to initialize some variables. One of the variables is a "demo" item,
that I use as a placeholder until the user choses something more specific.
I'm having trouble initializing the dummy. Here is my code:
(defun init
2008/12/11 Henrik Hjelte :
> I agree with Alex, just one perhaps obvious comment: I would have one
> transaction around cleaning up one blob-id, not a big transaction
> around cleaning up the whole blob table. If you do several
> transactions it doesn't lock up much, so it
> should be able to execu
HH> I agree with Alex, just one perhaps obvious comment: I would have one
HH> transaction around cleaning up one blob-id, not a big transaction
HH> around cleaning up the whole blob table. If you do several
HH> transactions it doesn't lock up much, so it
HH> should be able to execute at the sa
I agree with Alex, just one perhaps obvious comment: I would have one
transaction around cleaning up one blob-id, not a big transaction
around cleaning up the whole blob table. If you do several
transactions it doesn't lock up much, so it
should be able to execute at the same time as a database is
RS> then the slot definitions in the slot table are removed, but the
RS> actual slot _values_, which live in the blob table, are retained. Is
RS> this intended behaviour?
yep, it is. it sort of sucks, i know.
whether or not it becomes a problem depends on what kind of data
you store in slots.
15 matches
Mail list logo
