For now the easiest approach is to define-away the problem.
with-open-store is a convenience function for interactive development
and testing. It should not be used in production, a multi-store or
multi-threaded program. Opening and closing a store for small
operations comes with a signifi
IE> What interface do you use to deal with opening/closing separate
IE> connections in your system?
connection management is not a problem.
problem is that close-store unconditionally makes controller totally
unusable, and that might cause problem if there are some with-open-store
commands goin
What interface do you use to deal with opening/closing separate
connections in your system? You want to use the same handles in the
BDB backend and I don't think we want to have different interfaces for
different backends. There is some code for doing this automatically
by looking at uniq
Leslie P. Polzer wrote:
> On Fri, Nov 21, 2008 at 11:02:21AM +0100, Tayssir John Gabbour wrote:
>> foo-user> (asdf:oos 'asdf:load-op :elephant-tests)
>> ...
>> foo-user> (ele-tests::do-test-spec 'testthreads)
>> NIL
>
> In fact this should output a lot of stuff.
> How long does it take unti
Tayssir John Gabbour wrote:
> Leslie P. Polzer wrote:
> > On Fri, Nov 21, 2008 at 11:02:21AM +0100, Tayssir John Gabbour wrote:
> >> foo-user> (asdf:oos 'asdf:load-op :elephant-tests)
> >> ...
> >> foo-user> (ele-tests::do-test-spec 'testthreads)
> >> NIL
> >
> > In fact this should output a
On Fri, Nov 21, 2008 at 11:02:21AM +0100, Tayssir John Gabbour wrote:
>
> foo-user> (asdf:oos 'asdf:load-op :elephant-tests)
> ...
>
> foo-user> (ele-tests::do-test-spec 'testthreads)
> NIL
>
>
> I guess that's good. ;)
In fact this should output a lot of stuff.
How long does it take until retu
IE> with-open-store closes the store when you're done, null'ing out *store-
IE> controller*. With sufficient concurrency you are likely to get a race
IE> condition where the if stmt in with-city-store succeeds but the body
IE> fails since you aren't locking access to *store-controller*.
well,
> there's a new connection in the database, never dying and eventually
> overflowing Postgresql's limit. (That is, "select count(*) from
> pg_stat_activity;" has a new row each time). A couple DB people at
> work looked at the ele-postmodern code, and they say they don't see
> the connection being
Alex Mizrahi wrote:
> TJG> With Elephant under both Postmodern and CLSQL, I'm consistently losing
> TJG> my DB connection. This apparently happens when writing from fairly
> TJG> simultaneous threads. (Two threads may write to the same btree key at
> TJG> around the same time.)
>
> weird. could be
Hi Ian,
The problem is, suppose I just open a store controller at the very
beginning. If I execute either of the following:
(sb-thread:make-thread
(lambda ()
(get-value "foobar"
(get-from-root *my-btree-name*
:sc *my-store-controller*
(sb-th
with-open-store closes the store when you're done, null'ing out *store-
controller*. With sufficient concurrency you are likely to get a race
condition where the if stmt in with-city-store succeeds but the body
fails since you aren't locking access to *store-controller*.
Ian
On Nov 20, 200
TJG> With Elephant under both Postmodern and CLSQL, I'm consistently losing
TJG> my DB connection. This apparently happens when writing from fairly
TJG> simultaneous threads. (Two threads may write to the same btree key at
TJG> around the same time.)
weird. could be broken Lisp implementation,
12 matches
Mail list logo
