Thanks to those who responded to my query. Simon: It will be easier to code if every page commits, regardless of whether any write operations occurred (and rollback only error) - so your answer pleased me greatly.
Keith: Yes, you're right. I'm not passing a single database connection around, I'm using a pool. I've been thinking about using WAL, but I had reservations as it is not enabled by default. I'll have another look at it. Darren: I hadn't been considering transaction time. Now it occurs to me that writing data back to the user could indeed take time before the page code returns. Rather than add complexity to the page objects, I'm thinking about buffering their writes, so the transaction can be closed before any data goes over a network. This has other implications, so I'll think about this further, but I'd rather keep such considerations in one place rather than in each page object. Just to be clear, each page is stateless and many pages could be called at the same time. The question revolves around wrapping each page request in its own transaction - so each of the many page objects need not worry about such things and can focus on extracting and updating data. Your tangent conflicts with Simon, so I'm not sure who's right - I see both points - I'll have to think about this more. My database library does not support read-only transactions, which does simplify things (for better or worse). I could (if deemed beneficial) automate a rollback if no exec were called, instead of commit. Thanks again. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
