I think you need to find a connection pool implementation. I'm sure there's
some libraries for this but I haven't looked. At the very least, you do not
want to share a connection across two threads at the same time.
SQLAlchemy's awesome pool impls will ensure the connection is still alive
(not
On Wednesday, November 28, 2018 at 11:11:55 PM UTC-6, Lukasz Szybalski
wrote:
>
>
>
> On Monday, October 8, 2018 at 12:10:20 PM UTC-5, Michael Merickel wrote:
>>
>> If you are doing loading of data at "first run of the function" then you
>> have introduced a race condition in your app where
On Monday, October 8, 2018 at 12:10:20 PM UTC-5, Michael Merickel wrote:
>
> If you are doing loading of data at "first run of the function" then you
> have introduced a race condition in your app where unless you do
> appropriate locking, two threads (most wsgi servers serve a request per
>
On Tuesday, October 9, 2018 at 11:08:35 AM UTC-5, Bert JW Regeer wrote:
>
> I would disagree, heavily. You want to create your globals once, then
> fork. This way the memory used by said global can be shared between all of
> the processes. Instagram even added the ability to freeze items so
On Tuesday, October 9, 2018 at 12:08:35 PM UTC-4, Bert JW Regeer wrote:
>
> I would disagree, heavily. You want to create your globals once, then
> fork. This way the memory used by said global can be shared between all of
> the processes.
+1
--
You received this message because you are
I would disagree, heavily. You want to create your globals once, then fork.
This way the memory used by said global can be shared between all of the
processes. Instagram even added the ability to freeze items so that they don't
go through the normal GC cycle and thus don't accidentally cause
You run the same code at configure time and load it once per process. Even if
you do this once at request time or once at configure time you have to do it
once per process.
> On Oct 9, 2018, at 00:00, Thierry Florac wrote:
>
> And how do you handle such use case when working in a
>
And how do you handle such use case when working in a
multi-process/multi-hosts cluster configuration?
Le lun. 8 oct. 2018 à 19:10, Michael Merickel a écrit :
> If you are doing loading of data at "first run of the function" then you
> have introduced a race condition in your app where unless
On Mon, Oct 8, 2018 at 9:20 AM Lukasz Szybalski wrote:
> Is there a way to force this object to be "read only" or now allow
> modification, to prevent somebody else in some other sections of the code
> accidently modifies request.registry.mycontract?
def __setattr__(self, attr, value):
if
If you are doing loading of data at "first run of the function" then you
have introduced a race condition in your app where unless you do
appropriate locking, two threads (most wsgi servers serve a request per
thread) may both consider themselves the first run and load the data. The
only way to do
On Sunday, October 7, 2018 at 12:59:58 AM UTC-5, Michael Merickel wrote:
>
> This sounds like an application-global object. These are typically stored
> on the registry at config-time. For example, in your main you could set
> config.registry.foo = contract. The registry is available as
>
This sounds like an application-global object. These are typically stored
on the registry at config-time. For example, in your main you could set
config.registry.foo = contract. The registry is available as
request.registry and subsequently anything you add to it. You can see lots
of examples of
Hello,
I have an enterprise system that is creating a class but it takes a long
time to initiate. About 2 sec, 90K _setitem from pickle. Nothing to
profile, since OS cashes the file its as fast as it gets.
I'm trying to find a way in pyramid where I can:
#store below at start, of the process,
13 matches
Mail list logo
