On Wednesday 19 November 2008 19:47:48 Andrew Stone wrote: > Hi Jorge, > > Thanks for your reply. Unfortunately, I don't think that your solution > will quite work for my application, which it just occurred to me from > reading your solution is probably a pretty interesting (i.e. different) TG > application. > > I am essentially using TG to manage a live cluster of systems. So my > "model" isn't actually stored in the database, its pulled directly from the > cluster's current state. Now, I don't have threading issues -- if 2 users > get on at the same time nothing will die or crash. But what may happen is > that someone will be trying to upload new software onto a node at the same > time that another person is trying to reboot it! This is the sort of > operation I am trying to avoid. Since operations like "upload software" > span multiple web pages & requests, I can't use a simple thread lock (also, > I wouldn't want to lock someone out without a web response for more then a > few seconds). A simple way to do this is to only let 1 person with the > permissions to do things like reboot the system on at a time. > > So I really want to do something like write a custom "log in" that only > allows 1 user (of a certain group) to log in at a time. Or I could use a > global "lock" variable on the top of the relevant pages that only lets 1 > session through, and redirects all other requests. But to do any of these > things, I need to be able to examine all active sessions (I enabled the > idle timeout so the session will be destroyed if the user forgets to log > out) & I can't find an API to do so. I could keep track of the sessions > myself but then I would have to do my own idle timeout logic which might > not keep in sync with the idle timeout logic in TG, resulting in cases > where noone could log in, etc. > > Is there a way to get a list of all currently active sessions in TG?
I wouldn't go for something like that. Hooking into the session-mechanism is tedious, and error-prone. And it won't work for example if you'd extend the system to also have some commandline-tools (just in idea of course) You should instead create a database-residing lock. I'm *not* talking about a "select for update" here, albeit that must be issued most probably. Instead, you create a table with one row (or possibly more, if there are several things that can run in parallel) that has some columns like - name - locked (locked/unlocked) - when (when the lock has been acquired) - who (the person who did acquire the lock) Now on entry of a critical section, the TG-app tries to get that lock. If it fails, it will report that to the user, who has to wait. He will be presented with above information, so that he can possibly inquire at the current obtainer if the locks seems to be held unreasonably long. On leaving a critical section, you of course clear the lock. Depending on your database and transaction-model, acquisition and release pose some concurrent design issues, but these should be solvable. Diez --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
