--- Perrin Harkins <[EMAIL PROTECTED]> wrote: > It would be. Frankly, there is no value to the kind > of mutual exclusion > that the Apache::Session locking provides in a > typical web application. > If you use the null locker you will still get > atomic updates, but you > will have the possibility of someone opening up two > browser windows, > hitting submit in both, and having the last save > overwrite the values > from the first one, possibly losing some changes. > In most web apps, > that is not a big problem.
We talked about this, but in our case, I don't believe this will be an issue. > Note that this could become a problem if you use > sessions incorrectly by > putting tons of data in them. Most of your data > should have its own > normalized tables and persistence code. Sessions > are for storing tiny > little bits of data like the user's ID or some form > data that from a > multi-page form that hasn't been committed yet. We put almost nothing in the session other than the user id. There are three apps sharing the same session table, and I believe one app may put two or three other things other than the user id (like current page id and affiliate id...both which I should be able to remove someday:)...but never-the-less, very little data in the session. I've gotten most of my sessioning information from this list (and you), so I believe we are session correctly :) > If you look at the actual contents of > Apache::Session::MySQL, you'll see > that it's essentially just a config file. There's > no need to be > concerned about using Flex, but you could easilly > code up your own > Apache::Session::MySQLNoLocks by changing a line in > the current module. That's what I figured and that's what I'm going to do. Thanks again, -- md __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
