On Tue, Apr 07, 2009 at 01:26:31PM -0700, Maciej Katafiasz wrote: > in the course of implementing the perec-backed store, we ran into an > issue that needs a clarification as to what contract exactly holds > between Weblocks and stores. The issue is that perec has a very strict > requirement that *all* operations that touch the DB (including read DB- > backed objects' slots at any time) must be wrapped in a transaction. > However, it seems that Weblocks (or the grid widget anyway) tries to > read persistent objects outside of a transaction. That doesn't end too > well. Thus I'd like to request documentation and/or discussion of when > exactly the stores can expected the transactions to be active,
Nowhere right now; there are no guarantees. I suggest running the whole request in a perec txn if any of the stores are found to be perec ones. > who is responsible for activating and terminating transactions, Only the user right now. > and whether we're guaranteed not to end up in nested > transactions No guarantees like this, but you can easily guard against this in the begin/commit/abort-transaction store API functions. > or ones interleaved between different stores. That's a bit tricky. You need to audit/test Weblocks and perec somewhat to see where problems might arise. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "weblocks" 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/weblocks?hl=en -~----------~----~----~----~------~----~------~--~---
