Hi Tom, Depending on the structure you've created for your database tables, and assuming that you're using mySQL, why not do this:
1. The user sends their chat text to the server. 2. The server first echos or forwards the message to the recipient(s). 3. The server last saves the text in the appropriate table, using a combination of a datetime stamp, a unique user name, and/or an autoincrementing index key. Your application can throw away the result, or raise an error that is logged in the event of failure without interrupting the user experience. If you're just adding records to a table, I don't see why you'd need to enforce a write lock since the queries are going to be processed in the order in which they are received - use the datetime stamp and username to rebuild a "chat history" that should follow sequentially, and if not, you can structure a query that will return them in that fashion, even if they're not stored that way. I'm assuming you'll have multiple chat logs saved in the same table simultaneously? Once a day, or whenever you want, you can query that table and offload the logs, in whatever structured order you want, into a more official record of the chat logs. When you have lots of entries, at some point it is possible that if you use an autoincrement field this will reach its maximum value, so it's best to set this as something like an unsigned BIGINT and keep an eye on it so you can rotate these things off should they get too large. The write lock is useful when you're updating an existing record that could potentially have other callers writing to it - but in the case of an SQL record, the action of the second would clobber the first. A write lock if you're writing to a local text file is useful to ensure only one caller at a time is allowed to append to the file, but they all have to use and obey the lock permissions without exception - you could use this method as a running backup of whatever you store into the database (useful in the event that the database goes down or the connection to it is lost) and archive them on a periodic (say daily) basis, naming the files according to some kind of unique nomenclature that uses YYYYMMDD in the file name to identify it. One record per line, prepended with timestamps, perhaps. Depending on how critical it is to save every bit of text going across your chat service, I suppose there are a variety of approaches such as this that you could tailor to suit your needs. Nathan On Mon, 21 Aug 2006, Thomas Williams wrote: > Hi chaps, > My apoligies for the off topic, however this is the list that will most > likely be able to answer this. > > Our application will be sending user data to the red5 server, which in > turn may be stored in a database. For example one part of our > application includes a logged chat server (the logging is going into the > database). > > We were wondering what techniques we could use to make sure that when a > user sends a chat message to the server that they do not have to wait > for the entire SQL statement to complete before they received a response > (All that would be going into the database would be logging, so the user > would not need to know the result of the query, be it success or > failure). Because the planned usage of this database will be quite high, > queries could be waiting a significant amount of time to gain a write > lock. > > We have investigated the hibernate framework [hibernate.org], and > although it offers many refinements it doesn't directly address this > problem. > > So, does anyone else have any elegant solutions for this kind of > problem? > > Best regards, > Tom > > > _______________________________________________ > Red5 mailing list > [email protected] > http://osflash.org/mailman/listinfo/red5_osflash.org > _______________________________________________ Red5 mailing list [email protected] http://osflash.org/mailman/listinfo/red5_osflash.org
