-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
David Binger wrote:
[...]
> This change opens the door for a new type of client/server behavior,
> in the common situation where clients can have direct access to the
> underlying file. In particular, this new type of client could maintain
> an independent offset index, and do all reads directly, without
> interacting with the server at all. The server would handle all
> writes, and it would distribute offsets with invalidations, so that the
> index of each client would always reflect a consistent view of the
> database. Every client would need to be notified when the storage file was
> packed so that the local offset index could be reset. The result
> of this should be that clients see a consistent, though possibly
> not-quite-current view of the database as they are reading, and
> conflicts, if necessary, are handled when and if there is a commit.
> (That's what I'm thinking is MVCC.
> Please correct me if I am wrong about that.)
Yes, that could provide MVCC but you only benefice local clients able to
access the storage file. Depending of running clients locally could be a
scalability nightmare when the demand came. Loopback TCP connections are
fairly speedy already. In another life I did a python socket-like module
to be able to communicate processes using MMAPED files, avoiding TCP/IP.
But with current UNIXes and small objects (a few kbytes) the gain is
negligible, if any.
Durus client cache also relieves a lot of presure over the server process.
Three months ago I was testing a durus server patch to provide MVCC
semantic simply keeping around the old offset of modified objects to
serve other clients, but I drop that code because I have no real need
for MVCC. In my experience most conflicts are real ones, especially if
you design your application rightly. Of course your mileage may vary.
The server keept a "transaction ID". There was a global transaction ID
and a per-client transaction ID. There was also a python dictionary per
transaction ID keeping offsets for objects modified by newer
transactions. Client transaction ID was set to global transaction ID
when commit/abort. When all clients transaction IDs > minimun
transaction ID in the dictionary, I deleted that entry. No provision for
storage packing, since it was a prototype try-out.
So when a read request arrived, server tried to read the object as it
was in at the time when that client transaction started.
My BerkeleyDB backend doesn't keep around old versions when an object is
modified, but load previous version to be able to analyze inter-object
links and to garbage collection in background, just before updating the
object on disk. So I could simply keep old object versions around in RAM
while memory available...
As I said, MVCC had no real benefice with my usage profile, so I dropped
the code.
> That's it for the future. We also have a list of improvements
> that are already coming in Durus 3.5, which I hope we can release
> next month. The 3.5 changes will make make the server work better
> with Unix Domain Sockets. We're adding support for allocating
> oids in blocks, and for bulk-loading object records, among other
> things.
Will Durus 3.5 include the "page-in" code?.
- --
Jesus Cea Avion _/_/ _/_/_/ _/_/_/
jcea@argo.es http://www.argo.es/~jcea/ _/_/ _/_/ _/_/ _/_/ _/_/
jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/
_/_/ _/_/ _/_/ _/_/ _/_/
"Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/
"My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQCVAwUBRM6+mplgi5GaxT1NAQLkCwP8DPpud2lL1of385ClYoic8D3rsZO1TIKS
waj/IGzODwYVymPkIArq7zF8Uy/FPN8+znw9uL2BwZreKQK86CfYl2/ATBZ3oei9
M+k7E9Iwj3P7HSh6kz1Dr5FbWJVWYmGSCloRRGp0qwSZATwYxno+gVD5g1DEM/NB
4mBltCIrCEc=
=clCU
-----END PGP SIGNATURE-----