On Apr 15, 2009, at 1:13 PM, John Ours wrote:
On Apr 15, 2009, at 12:55 PM, Stamenkovic Florijan wrote:
And tougher still if the data you are caching can get modified on
the server while the client is disconnected. Then you have some
interesting update conflicts to handle. This can be a real tough
nut to crack.
Yeah, data freshness in general would be a pain. However one would
handle it, some serious confusion for the users is inevitable. The
only reasonable way out of this that I can see is to make the
cached data read-only.
We do these sort of occasionally-connected systems on the .NET
platform a lot using MSSQL Desktop -> MSSQL Server replication.
So, MS SQL on the server AND client? Was that Chuck that I just heard
screaming from the room?
Chuck?
Helloooo?
Chuck?
Hmm....
If you're clever about what the user needs statically and what they
need to update then it's not that bad. Take a salesman in the field
for example...his usage pattern is over a set of records for his
clients in his territory. He needs other data but probably doesn't
need to edit it when he's off-line, and changes to it can move much
more slowly than his own stuff. OCC is a pretty poor choice for a
system with high concurrency, but you can usually solve the business
problem by analyzing where concurrent access is likely and limiting
those operations when the user goes off-line.
John
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.com
This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
