Thanks for the clarification. It makes sense, and I understand that the browser is not a "controllable" client in the same sense as the other environments.
On Thu, 25 Mar 2004 15:28:45 -0500, Bill McCormick <[EMAIL PROTECTED]> wrote: >There is no instability in the %session.Preserve code. It will scale >quite well. The major issues are items two and three. Here are some >examples. > >You use the concurrency code. You have a lock. IE crashes on the client, >which it does....or the user closes there browser accidently - they >clicked on a link in an e-mail, the window got taken over to surf >somewhere else and they closed it. > >You now have a lock that cannot be removed till the session times out. >But you won't want a quick timeout because if you timeout from under the >user all your local variables and locks are lost and the user has to >start over from scratch...catch 22 now. Do I use short timeouts to free >objects/locks killing my users. Or long timeouts and run the risk that I >can have data be frozen for hours? > >The web is a stateless place, it is the only place I recommend not using >Cache's built in concurrency logic. If I have a state aware connection >in an environment where I have complete control over the client - VB, >Java, Telnet - concurrency works great. The browser is not that place. > >Skip Hill wrote: >> Bill, >> >> I'm trying to understand the basis of your comments about not using >> %Session.Preserve, but instead to build a "virtual lock" approach. >> >> Let's define a scenario. Given a well controlled situation where a CSP session >> is allowing a user to update an object. Let's further assume the user can't >> naviage around and about and leave something hanging, they either update the >> data, cancel the update, or close the session. >> >> The documentation notes that tying a process to one user results in "lack of >> scalability". But I'm not building an application that will scale up to >> thousands of users or even hundreds. It will range from 20-60 users at 90% of >> the installations, with a max of perhaps 100 users at the largest sites. These >> are the same 20-60 users that WILL have a process tied to their VB session. >> What's the problem with tying a process to the same 20-60 users through a CSP >> session? >> >> Is it because >> >> 1. Some inherent Cache instability in using the %Session.Preserve to hold a >> record lock? >> >> 2. It's really difficult to control what happens with the %Session because of >> the inability to control what happens from a browser? I'm thinking that from VB, >> I can control things well enough to guarantee that locks will be released and >> objects cleared, but I realize that's not easy and perhaps not possible from a >> browser CSP session. >> >> 3. With a virtual locking approach, where a global structure contains the >> information about what's going on, that ultimately it is "cleaner", as you say, >> than dealing with timeouts and other complications of the %Session.Preserve. >> >> 4. Or, finally, is it because while %Session.Preserve works well, and can be >> implemented without unreasonable difficulty, that applications generally get >> pressed to scale up, which get's them into performance problems. >> >> Skip >> >> >> On Thu, 11 Mar 2004 12:43:23 -0500, Bill McCormick <[EMAIL PROTECTED]> >> wrote: >> >> >>>Look at %session.Preserve property. It handles state aware for csp. IN >>>general I do not recommend it. Using a "virtual lock" via a home made >>>global structure is cleaner in my opinion. >>> >>>Ben Taylor wrote: >>> >>> >>>> >>>>Peter Cooper wrote: >>>> >>>> >>>>>Skip >>>>> >>>>>Denver's code (last line) is the key - he is locking some "phantom" >>>>>entry - ie not an actual real global node - the entry is made in the >>>>>lock table separate from a lock on the physical data >>>>> >>>>>This is locking at some application meta level rather than specific >>>>>global data >>>>>and it works very well >>>>> >>>>>but only if you have state aware comms between the client and the >>>>>server (telnet session, cache factory, odbc (I believe), and state >>>>>aware CSP) >>>> >>>>Peter, >>>> >>>>Exactly how does one have a state aware CSP? I would be very interested >>>>to know about that. Thanks >>>> >>>>Ben >>>> >>>> >>>>>it will not work with stateless sessions though - all locks are >>>>>cleared by the csp server process once the page has been delivered >>>>>or in SOAP transactions >>>>> >>>>>to "lock" here you have to make entries in some sort of persistent >>>>>class/global >>>>>and ensure that they are tidied up at session end - also you have to >>>>>deal with client navigation via the back button >>>>> >>>>>I am not sure that this can be done 100% satisfactorally >>>>> >>>>>the other approach is to use optimistic updating and keep track of a >>>>>token in the persistent class indicating the save version - when a >>>>>cleint requests an update the object save processing checks the token >>>>>sent to the client against the current saved value and if they are >>>>>different then it fails >>>>> >>>>>Peter >>>>> >>>>> >>>>>On Wed, 10 Mar 2004 08:44:03 -0600, Skip Hill <[EMAIL PROTECTED]> >>>>>wrote: >>>>> >>>>> >>>>> >>>>>>I'm needing some help understanding how to utilize the Cache >>>>>>Concurrency options >>>>>>in my application. >>>>>> >>>>>>I'm used to an environment where a lock has the attributes of >>>>>>allowing anybody >>>>>>else to read, but nobody else to lock. It therefore provides >>>>>>"exclusive" access >>>>>>to an object for the purposes of updates. Other users are forced (by the >>>>>>application logic) to either wait or give up and try later, BEFORE >>>>>>they can even >>>>>>get started on an update. It's simple, with the advantage that there >>>>>>are no >>>>>>situations where updates will be lost. >>>>>> >>>>>>I'm struggling with how to use the available Concurrency locks in >>>>>>Cache to >>>>>>implement this, or some other practical approach to locking and >>>>>>updating class >>>>>>data. >>>>>> >>>>>>I tried the Exclusive lock, and discovered that it inhibits even no >>>>>>locking >>>>>>%OpenId reads, so that does not work for me. >>>>>> >>>>>>The Shared/Retained looked promising, but it presents a problem I >>>>>>would rather >>>>>>not have to deal with in my application. Unless I misunderstand >>>>>>something, the >>>>>>typical flow would be >>>>>> Obtain Shared/Retained lock >>>>>> Allow user to do whatever that effects changes to the data >>>>>> Attempt to obtain an Exclusive lock with %UpgradeConcurrency >>>>>> If it succeeds, %Save and we're done >>>>>> If it fails, wait and try again, or ask the user to lose their >>>>>>changes >>>>>> >>>>>>And that's the problem, if two users get started, and they both make >>>>>>changes, >>>>>>they will be deadlocked until one of them gives up. >>>>>> >>>>>>Here are my questions; >>>>>> >>>>>>1. The implementation of these Concurrency options seems strange. Is >>>>>>the design >>>>>>philosophy oriented toward giving developers really fundamental >>>>>>control of >>>>>>Cache's internal mechanisms, so that we can build on them to provide >>>>>>the kinds >>>>>>of locking we know our application will work best with? >>>>>> >>>>>>2. Or am I missing the big picture somewhere here, and if so, I hope >>>>>>someone >>>>>>will enlighten me. Is there some generally accepted and proven >>>>>>approach that is >>>>>>working in the real world with lots of users, and locks potentially >>>>>>persisting >>>>>>for 5-10 minutes before changes are saved? >>>>>> >>>>>>3. If 1 is true, then how do you implement an approach that allows >>>>>>one user to >>>>>>lock a class object "record" for potential updates, allows all others >>>>>>to read >>>>>>it, and will never lead to a deadlock or a requirement that a user >>>>>>abandon >>>>>>changes? >>>>>> >>>>>>Any help will be appreciated >>>>>>Skip Hill >>>>> >>>>> >>>>> >>
