> You're not suggesting write-locking records during edits, do > you? :) How about the situation where the client crashes, the webapp is > closed by hte user, the session of the webapp is ended due to time > expiration, the client gets disconnected from the network (modem hangs > up :)) etc. ? That lock then remains. I dont' think that's a good idea.
Sure I am. I didn't say that I would always do it. Your problem, Frans, and why many others seem to think you're such a blowhard, is that you make too many sweeping statements. I will answer your question with just one decent example. Hopefully this will convince you that not all people who disagree with you are idiots. Here it is (ready?): did you ever use VSS, or any other source control system? There are many, many real-world examples of the same strategy to which I can point. To address your concerns, it's often the case that write locks are set with a timeout when they're used at all, but not in all cases; VSS is a case in point. All rudeness aside, I sometimes gain knowledge from your posts. I just wish I didn't have to wade through so much text to get to it, and that you weren't so defensive. Most people aren't right all the time, especially the ones who have opinions on many things and sometimes think out loud. That's certainly no crime; I'm the same way! > What's auto-persistence and in that light 'not auto-persisted' ? > If these uber-vague terms without any real meaning aren't defined, this > discussion ends up being a very academic babbling between people who > don't understand the true meaning of what persistence really is. In that > light, you said "Yeah, Thomas' post was crappy." No it wasn't. It was > spot on. He clearly described what should be described. Okay, that's a valid point. I've been assuming that "transparent persistence" (for which I seem to have substituted "automatic persistence") means that some tool generates persistence code so that you don't have to, and maybe as well that this code is hidden so that when you set a field or something, an object is persisted at that time. I imagine that there could be very many different implementations of this idea, each with its different characteristics: some allowing explicit control over saving, some not, etc. This would be similar to using a database in autocommit mode versus using explicit transactions, I imagine, but I don't know. Is this so unreasonable to imagine? No. Would some people like it? Yes. Is it important to define terms exactly? Yes, absolutely, unless you feel like speaking in more general terms. I think it would have been good to open the discussion of "transparent persistence" with a pretty precise definition of what was meant, and I'd bet that a better term to describe what is meant by the phrase could be found. > you said "Yeah, Thomas' post was crappy." No it wasn't. It was > spot on. I meant that it was too rude, not necessarily that he was wrong, and you know it. I'm afraid that being Dutch doesn't let you get out of this one. You can try that "no speaka da English well" bit again, but you're one of the best writers on this list; that's one reason why people take you seriously. Your language skills are good enough to know that if Thomas behaved like that at a bar, he'd have a fight on his hands. People read these things (and post to them if they aren't afraid of getting lambasted by hotheads) because they care about what they do! I'd never be so disrespectful to someone that didn't deserve it. Jeff =================================== This list is hosted by DevelopMentorŪ http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 26 Jan 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com
