Am 20.03.2014 13:36, schrieb Jens W. Klein: > On 2014-03-18 14:39, Gerhard Schmidt wrote: >> On 18.03.2014 14:08, Chris Rossi wrote: >>> It should start its own connection via the standard ZODB API. You might >>> consider moving the extra work to a different process. Redis pub/sub or >>> list objects are good ways to communicate and set up a primitive, simple >>> queue. I prefer that to more complex queue/messaging frameworks. YMMV. >> >> Right now I have no ZEO running. In Production there will be a ZEO but >> while developing a ZEO server simply adds to complexity and makes >> debugging even more pain in the ass. > > Well, really? A ZEO-Client-Server in development enables you to connect > with two threads, i.e. one debugging console, one serving requests. I > prefer this way of debugging. But yes - the zeoserver needs to be > started, thats all. Using buildout setup/configuration is very easy.
The ZODB is Multithreading. You can open multiple connections without a
zeo server within the same process. A ZEO Server is needed when you need
more than one process or want to use one ZODB on multiple Servers.
>> It might solve me problem if I could start a worker thread at
>> application start an send the task via queue there but there is still
>> the problem to get a thread with access to the zodb started. I know that
>> it's possible to use one ZODB connection in multiple threads, Zope does
>> it and pyramid does it. The question is how to fork a new subconnection
>> or transaction and pass it to the new thread.
>
> Using ZEO and if youre running exact one worker thread: Let the
> request-process(s) store the tasks in the ZODB and fetch it task by task
> in a worker process. Dont forget to keep transaction (begin to commit)
> time at both, request and worker, as short as possible to avoid database
> conflicts.
>
> If you need more than one worker there are solutions around AMQP (i.e.
> rabbitmq) or redis helping you with queue management. I used such only
> with Zope2 so far, but the principle is very basic. So I'am sure it
> works in a pyramid environment well.
Zope2 uses i default config 4 threads. And as many connection as needed
to serve simultaneous requests.
I am running a Zope2 system with 64 Frontend Zope Server and one Backend
ZEO for quite some time ( > 10 Years ) so i know quite a lot about ZODB
and zeo. My Solution to the Problem is the folowing function pair.
def startZODBAwarThread(context, method, delay=0, args=None, kwargs=None):
if args == None :
args = ()
if kwargs == None :
kwargs = {}
db = context._p_jar._db
contextpath = resource_path(context).split('/')[1:]
meth = getattr(context, method, None)
if meth != None and callable(meth) :
thread.start_new(initZODBAwarThread, (db, contextpath, method,
delay, args, kwargs))
def initZODBAwarThread(db, contextpath, method, delay, args, kwargs):
time.sleep(delay)
connection = db.open()
rc = connection.root._root['app_root']
context = rc
while contextpath and contextpath[0] != '' :
context = context[contextpath.pop(0)]
import transaction
transaction.begin()
meth = getattr(context, method)
meth(*args, **kwargs)
transaction.commit()
connection.close()
delay should be at leased 1 to avoid conflicts because accessing and
possibly changing the same object in both threads.
Regards
Estartu
--
----------------------------------------------------------------------------
Gerhard Schmidt | http://www.augusta.de/~estartu/ |
Fischbachweg 3 | | PGP Public Key
86856 Hiltenfingen | JabberID: [email protected] | auf Anfrage/
Tel: 08232 77 36 4 | | on request
Fax: 08232 77 36 3 | |
0xCE4C9411.asc
Description: application/pgp-keys
<<attachment: estartu.vcf>>
signature.asc
Description: OpenPGP digital signature
