Previously DavidG wrote:
> What about a separate process (a daemon, let's say) that runs in the
> background? If both this process and the pylons process with it's
> multiple threads read and write to the database, is explicit locking
> required?
No. The SQL database will take care of all that.
What about a separate process (a daemon, let's say) that runs in the
background? If both this process and the pylons process with it's
multiple threads read and write to the database, is explicit locking
required?
I am looking to have pylons control/monitor the work, but the work
will be done by
On May 6, 2009, at 6:43 PM, Jeremy Burton wrote:
>
>
> Pylons works superbly out-of-the-box with SQLAlchemy if your web
> application solely responds to HTTP requests.
>
> However, it seems to me that most non-trivial web applications
> (including mine) will inevitably need to have additiona
On Wed, 6 May 2009 15:43:22 -0700 (PDT), Jeremy Burton
wrote:
> My question is what do people suggest are the best approaches for a
> database locking scheme using Pylons and SQLAlchemy?
I may be misunderstanding your question completely, but I'd have thought if you
use a transactional/ACID c
Pylons works superbly out-of-the-box with SQLAlchemy if your web application
solely responds to HTTP requests.
However, it seems to me that most non-trivial web applications (including mine)
will inevitably need to have additional threads performing other tasks, e.g.
mail send/receive, that a
