There is no test coverage as of yet, and there are still some bugs, but I've
implemented this concept here:http://github.com/11craft/duruses/

The client and server side are more or less ported from the Durus code, with
some changes:

- server side is asynchronous, using http://code.google.com/p/cogen/
    (was remarkably easy to port, kudos to cogen team for that)
- client side is synchronous
    (this is what i want for now but would be easy to make an async version
in the future)
- changes to the wire protocol
    - port is 22972
    - protocol version is 20001
    - introduce some new server-level commands
    - attach database name to db-level commands


I am able to do things like this:

Shell 1:
$ duruses-server play.duruses
Listening on 127.0.0.1:22972

Shell 2:
$ duruses-client
>>> from durus.connection import Connection
>>> c_foo = Connection(client.storage('foo'))
>>> c_bar = Connection(client.storage('bar'))
>>> client.list_open()
['foo', 'bar']
>>> c_foo.root['abc'] = 123
>>> c_bar.root['def'] = 456
>>> c_foo.commit()
>>> c_bar.commit()
>>> from duruses.client import Client
>>> client2 = Client()
>>> c2_foo = Connection(client2.storage('foo'))
>>> c2_bar = Connection(client2.storage('bar'))
>>> c2_foo.root.keys()
--- ['abc']
>>> c2_bar.root.keys()
--- ['def']
>>> c2_foo.root['abc'] += 1
>>> c2_foo.commit()

However abort() doesn't quite work yet.

>>> c_foo.root['abc']
--- 123
>>> c_foo.abort()
>>> c_foo.root['abc']
--- 123


I also discovered a starvation situation when calling abort() twice.  That's
probably why the above didn't work.  :)



On Tue, Sep 15, 2009 at 09:21, Matthew Scott  wrote:

> In the last message I posted, I noted that Durus appears to only support
> one file per server process.
> As one of my potential use cases for multi-process Durus involves having
> more than one database open.  Furthermore, I may be creating new databases
> on the fly.  Transactions would not cross database boundaries.
>
> Perhaps a solution to my concurrency woes would be to create an extended
> Durus server that operated in the same manner as the current Durus server,
> but had some additional high-level operations.
>
> Each client side process or thread would have a "service connection" that
> would talk to the server.
>
> The server would operate on a directory of Durus files, rather than an
> individual file.
>
> The client would create a "database connection" that would be mediated by
> the service connection and have the same API as the current ClientStorage.
>  Essentially, database-level operations would be tagged with the name or ID
> of a database but would be formatted and acted upon in the same manner as a
> single-database server.
>
> The service connection would have some additional operations available:
>
> - open a named database (creating it if it doesn't yet exist)
> - close a named database
> - destroy a named database
> - list available database names
> - list open database names
>
> Thoughts?
>
> --
> Matthew R. Scott
>



--
Matthew R. Scott