On 11/5/06, Ben Sizer <[EMAIL PROTECTED]> wrote: > > Jorge Godoy wrote: > > "Ben Sizer" <[EMAIL PROTECTED]> writes: > > > > > You were probably clear, but I don't know much about the detail of > > > database transactions and so on. But even if I drop down to the > > > database level and make the update directly, can I be sure that the > > > correct values propagated up to SQLObject in the other threads? > > > > In a standard TG application, the way it is designed in 1.0+ you should be > > safe on every exposed method. It starts a transaction that reads data from > > the DB. > > > > I believe that the only way you'll guarantee that it works for you is > > writing > > a small test case. One thread modifies data and the other reads it. > > It's not really possible to use test cases for synchronisation problems > though. They might work 10000 times in testing and then fail the > 10001st time when the instruction interleaving differs slightly, due to > the system load being higher, or some cache being more or less full, > etc. > > If you know which methods are synchronised and which ones aren't, then > it's possible to prove whether it will always work or not. > Unfortunately I don't have this sort of information and I was hoping > someone here would.
Audit the source then. See what kind of locking it tries to do. The safest thing to do of course is to only send immutable objects across threads, or deep copies of mutable objects (message passing). Pretty hard to screw that up. -bob --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
