On Tue, 2010-03-16 at 14:33 +0100, Senko Rasic wrote: > > A logger doesn't need to push loads of data at the same time. But it > > might need instead to rollback. Currently we don't need it, though. > > Hm, in which cases (besides error-while-logging?) would a rollback be > needed?
None. Usually the pattern is "send and forget". Each store will handle the message independently. My point was just hypothetical, if TPL needed transactional writings, it would be to be able to roll the data back. It would be interesting for a logstore to be able to roll back its operations on message M, if another logstore fails in processing M. Interesting but not strictly necessary, IMHO. Also on errors, currently we do atomic writings (usually a single updated/insert per message) even without transactions. Different logstores work independently, so no real need of rolling back if "the next" storing operation fails. I'd try to keep it simple and limit any use but the basic storing/querying. The safe way. It's always possible to enhance TPL use of SQLite when things work :) > Time/message count based transactioning might make sense. E.g. don't log > more than once a second, or more than once in 5 seconds unless more than > 100 messages are queued. But in this case, there's an issue of lag Well, on this scenario, what I said (a logger doesn't need to push loads of data at the same time) fails :) In a embedded device scenario, though, joining a high traffic chatroom would be rare and probably some sort of advice to turn off logging for the account would be interesting. In the case of 100+ enqueued messages, a transactional INSERT would be helpful. I suppose fdatasync() called just once instead of N, reducing syncing time notably. C. _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
