Re: fleeing sql

Riccardo Cohen <[email protected]> Thu, 09 Aug 2007 09:53:14 +0200
Newsgroups gmane.comp.db.metakit
Organization Articque
Message-ID <[email protected]>
About multi threading in a client application, my opinion is similar :=20
you have to lock something for writing. I don't know however the effect=20
of a write operation while another thread is reading... maybe memory=20
mapped file would save you, but I wouldn't bet on it.

On the other hand, in a web environment, where multiple processes would=20
access the same metakit file, my opinion is that the "file lock" method=20
as you explained cannot be reliable.

If I had to use metakit in an HTTP server-side application, and if I=20
needed a write access, I would build a single process on the server that=20
does all metakit access for all processes, and I would talk to that=20
single process with sockets. Of course you loose the easy of metakit=20
API, but your server is safe.

As I mentioned, I'm not sure of the effect of a write operation while=20
another thread/process is reading. So I would also include read=20
operations on this single process.

Maybe I'm wrong, please let me know.


David McNab wrote:
> On Wed, 2007-08-08 at 12:34 -0700, abused by speech recognition wrote:
>> If I remember correctly, metakit is multi-reader single writer right?
>> since I need multi-writer, guess I'm best solving that with embedding
>> metakit in a server using internal access locks?  does metakit work in
>> a python multi threaded environment either as multi thread access or a
>> single thread fed by multiple request threads/
>>
>> thanks for any feedback
>=20
> In a python single-process multi-threading environment, I'm sure that
> metakit could be made to work well, even if you have to surround the
> access statements in each thread with .acquire() and .release() of a
> threading.Lock object.
>=20
> I'm also interested in a multi-process scenario, such as CGI-based web
> server. This could be made to work well by tuning the http
> request/response cycle:
>=20
>  - create a metakit.storage() object at start of the http response
>    cycle, with the database open in read mode
>=20
>  - for a very small part of the http response cycle:
>      - acquire a file lock on the metakit database file
>      - create another metakit.storage() object on the file, this one
>        with the database open in read/write mode
>      - perform all needed write operations
>      - commit() the the read-write storage object
>      - del the read-write storage object
>      - release the file lock
>=20
>  - continue with the rest of the http response cycle, using the
>    read-only instance of the storage object
>=20
> The smaller the 'write window', the less the performance impact in a
> busy server environment.
>=20
> My questions on this scenario:
>  - would it work?
>  - would there be any problems with having two different metakit.storage
>    objects open at the same time in the same process, one with readonly
>    access and one with read/write access?
>  - how would it compare, performance-wise, to a DB built for concurrency
>    such as MySQL?
>=20
> Cautions with this approach:
>  - all View and row objects acquired from the read-write storage object
>    would have to be freed (ie, not stored in any object instances or
>    globals or closure-locals spaces) prior to doing the commit
>=20
> Metakit can offer significant speed and simplification over *SQL
> databases. Mk4Py allows a friendly object interface to views and rows,
> where to get the same for *SQL databases, one needs to load in something
> like SQLObject, which is hugely expensive.
>=20
> I would be interested in people's thoughts on all this.
>=20
> Cheers
> David
>=20
>=20
>=20
>=20
> >=20
>=20

--=20
Tr=E8s cordialement,

Riccardo Cohen
ligne directe : 02-47-49-63-24
-------------------------------------------
Articque
http://www.articque.com
149 av G=E9n=E9ral de Gaulle
37230 Fondettes - France
tel : 02-47-49-90-49
fax : 02-47-49-91-49

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the "metakit" group.=

To post to this group, send email to [email protected]
To unsubscribe from this group, send email to metakit-unsubscribe@googlegrou=
ps.com
For more options, visit this group at http://groups.google.com/group/metakit=
?hl=3Den
-~----------~----~----~----~------~----~------~--~---