Using ElementTree as backend for a chat web application issues

[Marcelo de Moraes Serpa]

Well folks, I appreciate your help, but I've got the problem solved by
re-implementing the chat backend (server) in Rails. It is working great now
(persisting the data in a mysql database, instead of XML files).

At least this has led me to search more about concurrent issues and
programming. I'm still confused on why this doesn't happen with my Rails
backend, but I will eventually find out. Living and learning.

Thanks for the attention,

Marcelo.

On Wed, Jun 11, 2008 at 12:47 AM, Gabriel Genellina <gagsl-py2 at yahoo.com.ar>
wrote:

> En Mon, 09 Jun 2008 15:32:00 -0300, Marcelo de Moraes Serpa <
> celoserpa at gmail.com> escribió:
>
>  I've built a chat with a front-end Ajax client and backend usign
>> ElementTree
>> to persist the data.
>>
>> In some circunstances I could not yet discover (it seems random) when I
>> edit/save the structure, the structure gets corrupted, elementree seems to
>> get lost in its internal "cursor", usually something like this happens:
>>
>> <backend>
>>  <chat_list>
>>   <chat id="1">
>>   <chat id="2">
>>  </chat_list>
>> </backend>id="3"/></backend>
>>
>> Pretty strange, and it drives the whole application unusable.
>>
>> I don't know if the concurrent nature of the application (multiple users
>> using the client at almost the same time and sending data to the server
>> which in turn must save the data to the same global.xml file) has
>> something
>> to do with it - I don't know if ElementTree is suitable for this kind of
>> thing. How to hanlde this concurrent issue?
>>
>
> I don't think it's a problem with ElementTree. Perhaps you are writing the
> same (global) configuration file from several threads at the same time? You
> may need some locking mechanism in that case.
>
> --
> Gabriel Genellina
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20080611/8cea67af/attachment-0001.html>