In my experience, the database engine itself does a pretty good job of managing concurrent connections like this out of the box, which is much of the reason why connection pooling is so effective.
Of course, thinks can be a bit interesting on the database side if you want to get really obsessive about performance, with possibilities such as tinkering with page sizes, locking strategies, and such like, but it's extremely rare for this to be a bottleneck in an application. However... For the example you've given, I'd just run a dedicated actor to persist chat messages. There's no need to wait for a message to be persisted before displaying it to the user, so asynchronous messages can really help out here. On Sun, Oct 4, 2009 at 6:41 PM, donfranciscodequevedo <donfranciscodequev...@gmail.com> wrote: > > I have read that the Lift framework supports the CometActor model. > As far as I understand this is achieved by creating many threads out > of some thread pool, each of which handles one or more client socket > connection to a client. > > My question is, what kind of approach Lift takes to handle access from > such threads to a shared object, e.g. a database? > > Many thread based applications use locks to access shared data, which > however won't scale well. I read that better models would be timestamp > ordering or multiversion concurrency control like e.g. used by > CouchDB. > > Perhaps this is also handled automatically by the database and I don't > have to bother about it at all from my application? Is it save to use > a database connection from different threads? > > A simple example that came to my mind would be a Comet chat > application, where one wants to save the communication to a database. > How would the concurrent write requests from two threads to the > database be handled in such case? > > > Best regards > > > Gregor > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
