-
Notifications
You must be signed in to change notification settings - Fork 424
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make sure this app is thread-safe #2
Comments
Ok, so I don't know threads very deeply yet, but I asked this on #django-dev IRC channel:
and got this response:
(akaariai is one of the core developers) So I guess it will be safe after I send the patch for #93 ! |
I have been thinking about his a bit:
|
Hi Walkman, yes, it is most likely problematic changing Cheers |
Unfortunately, South doesn't use this (It just modifies INSTALLED_APPS), so if migrations are involved, this is very much a problem! |
Well, I'm not sure if we can do anything about it...maybe some sort of global lock when a tenant is being created and south is used? This lock would only block new tenants from being created, users will still be allowed to navigate freely |
Yeah, I thought about the same! But to make it totally safe, it should block every new request to the Django process until that migration is ready... because a migration is modifying the global state of the whole Django process! Maybe redirect the request to a static template which tells something is going on, try again, but it would not be very nice. |
I have an idea: attach a patched South version next to this app so it would work without problems. It should be easy because the app modification method already written in |
I discussed this on the #django IRC channel and the only good solution for this is to put the syncing process into a worker!
|
I suggest removing the database syncing part ( |
Hey Walkman, thanks for doing all this research about the topic! Syncing the tenant on a separate worker seems like a very good idea. I think we don't have to remove anything, but rather ensure that the relevant parts (editing the settings and syncing the tenant) happen in a new process. It'd be nice if we can somehow start and wait until this new process is done, so that behavior stays pretty much the same. That is, tenant creation still happens synchronously -- we could add an option so that it happens asynchronously. It'd be nice if we could also guarantee that this new change doesn't break anyone's code -- I myself have used Thanks again for everything, you have been a big help! 👍 |
I looked into this even more and I almost sure even changing |
Nice catch! I guess we won't have to worry about that anymore when we start syncing tenants on a separate process. I apologize that I haven't been able to review your and the other patches, I'm a little short on time until the end of the year. I promise I'll catch up as soon as possible. Thanks for all the help! |
@bernardopires @walkman Any progress on this? I'm available to help out if needed. Also, I was thinking about another approach to setting schemas on connection using a connection pool. We could ship a connection pool that would map and pool connections to domain url or customer ID. So basically, all tenant sites will have their own (or set of) dedicated connections to talk to the DB and we won't be doing set/unset tenant dance before/after every request. This way there will NEVER be any risk of accidentally changing the schema on the connection. I don't know how much of an advantage this bring to the table but I guess it was worth a shout. S |
Hey owais, I'm not familiar with how connection pools work, but wouldn't this mean there'd need to be at least one open connection per tenant? How would this work with servers that have multiple processes and multiple threads? I think the biggest issue right now is that tenants are being created (and therefore |
Aside from the syncdb issues, are there any known issues related to using this with gunicorn + gevent? Has anyone attempted this yet? I am trying to get a more precise understanding of how gevent operates, but from the surface it appears that the DatabaseWrapper is still unique to each thread, so there shouldn't be an inherent threading issue. Does anyone have any more insight regarding this? |
I used it in production for a long time with apache and had no problems at all. There were some weird bugs like |
I'm trying to follow this thread and from what I read it appears that two Clients can not be created at the same time. If that is correct I don't know how this solution could be used on even a moderately busy site. Is the reason that a new Client creation alters the database to add a schema and that is not a safe operation? |
Is a |
Thanks again! Yes, that would be ideal to create tenants on a separate process. |
Use old style indexing in format strings #2
This is being used right now in production on a small project and I have made an attempt to make it thread-safe, but I'm a complete beginner at this subject. Any help on this would be HIGHLY appreciated. Can someone please check if the custom
postgresql_backend
is thread-safe? If there is a way to write a test for this, it would be awesome.The text was updated successfully, but these errors were encountered: