Hi Richard, Re: synchronizing back end data, that's probably the right way to go for almost any application (although Nando's advice is perfect for situations like multi-screen forms where changing data and committing the change may be treated as distinct events). I would like to mention that you are still not 100% safe from concurrency problems.
Lets say I log in, create two browser windows and open "edit user" on both. If I change something on one and save it and then change something on the other and save it, I'll get data loss. This is less likely to happen than a situation where I just naively populate a session object and hope it'll never change (which is where you'd use the IsDirty to get the performance gains of session storage while still being able to get the benefits of realoading the data any time it changed), but it can happen. In the vast majority of cases where you're talking about user editing their data this small likelihood of data loss won't be a problem, but if it is you'll need to add the lastupdated or field level data checking to make sure you never have data loss. Of course, you could also try pessimistic locking where you distinguish a "get to edit" from any other type of "get" method and lock the data for editing until it is checked back in. I've never seen a good use case for implementing this on a stateless web application as it becomes very easy to end up with situations where you have to log out and log in to edit because you opened two edit forms and then closed the wrong one. (Not saying there aren't such use cases out there somewhere, but they are pretty rare). Pessimistic locking also gets very hairy when you have objects with different screens for editing differenmt properties as you have to track checkin/checkout at a record level which is not trivial. Best Wishes, Peter -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Sent: Sunday, June 25, 2006 11:57 AM To: CFCDev@cfczone.org Subject: RE: [CFCDev] Instances and persisted data Finally got my head round the session façade concept I think Found an example (Brian Koteks bookstore application www.briankotek.com) which illustrates this. My object is still in the session scope, but that is handled by another object which is responsible for creating it in that scope and getting setting it's properties. As regards synchronising instance/backend data, I'm going to take Dave's advice at the top of this thread and commit the data as it is changed Thanks everyone -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Ross Sent: 25 June 2006 17:22 To: CFCDev@cfczone.org Subject: Re: [CFCDev] Instances and persisted data That's not my advice. If it's session-based data, put it in the session. If it needs updating, update it. Why create additional load on your system by recreating everything upon each request? ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org
