Re: Session cache, lock and write

Hi! > I agree. > This behavior could be dangerous just like SQL without transaction. No, it is way, way more dangerous. SQL only changes the rows it touches, session saves the whole session. It would be as if every SQL statement would read whole database when you start the application, changed something and then wrote the whole database - even the data you never intended to touch - back to the disk, wiping out all the changes in all other tables other applications changed since you have read it. Unlike SQL, which operates only on small piece of data at a time usually, session writes the whole thing in one bunch. There is no partial reads in writes. So situation here is not even close to SQL - it is way worse. The frame of breakage is much larger and the breakage is practically guaranteed to occur. > It's dangerous, but if user know what they are doing, it could be safe and > application runs faster. This should be documented well. IMO. I don't think there's a user that knows that they are doing enough to use such thing (because that means they have to know exactly how every request in their app ever is serialized and what the exact timing of every request is, now and forever in the future, and I do not see how it is feasible). There might be ones that think they do, but that would be a dangerous delusion, and I don't think we should support it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227