Re: lovely.memcached + Zope2/Five

Andreas Gabriel <[email protected]>
Newsgroups gmane.comp.web.zope.german
Organization Hochschulrechenzentrum Philipps-Universitaet Marburg
Message-ID <[email protected]>
Hallo,

Jens W. Klein schrieb:
> Danke, das ist auch meine Frage? Ich sehe keinen direkten Sinn threading
> local zu binden.

Wir cachen keine gerenderten Templates oder Ähnliches, sondern haben
eine Locking-Factory auf Memcached-Basis implementiert, die jetzt ein
Upgrade von zope2.7 nach zope2.1x erfährt. Insbesondere
bei der RLock-Implementation ist es wichtig, welcher Host:Thread
das Lock acquiriert hat. Sinn der ganzen Sache ist, den ZEO-Clienten
einen Shared-Locking-Mechanismus zu bieten, um ConflictErrors zu
minimieren. Zum Beispiel haben wir das Shared-Locking für das Indizieren
des ZCatalogs (catalog_object) aktiviert. Der Catalog erweist sich bei
Schreibvorgängen immer wieder als Flaschenhals und somit als Quelle für
ConflictErrors. Es ist meist günstiger auf einen freien Slot zu warten
als immer wieder durch eine abgebrochene Transaktion gezwungen zu
werden, alles neu zu berechnen. Wenn das Shared-Locking ausfallen
sollte, schlägt immer noch Zope's Transaktionskontrolle zu.

s.a.

https://svn.plone.org/svn/collective/unimr.memcachedlock/trunk/README.txt


Gruß
Andreas

-- 
Dr. Andreas Gabriel, Hochschulrechenzentrum
Hans-Meerwein-Str., 35032 Marburg, fon +49 (0)6421 28-23560 fax -26994
----------------- Philipps-Universitaet Marburg ----------------------



_______________________________________________
zope mailing list
[email protected]
https://mail.dzug.org/mailman/listinfo/zope
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.