Re: JavaClient offline storage / replication
Re: JavaClient offline storage / replication
- Subject: Re: JavaClient offline storage / replication
- From: John Ours <email@hidden>
- Date: Wed, 15 Apr 2009 22:44:08 -0400
On Apr 15, 2009, at 5:52 PM, Stamenkovic Florijan wrote:
On Apr 15, 2009, at 17:32, Lachlan Deck wrote:
On 16/04/2009, at 1:51 AM, Stamenkovic Florijan wrote:
It would also open up a can of worms too. With normal connections
you can get an optimistic locking failure and can present this
immediately to the user. In its absence you'd either not be able to
use any locking at all (and thus the last update wins however old
it may have been queued) or have the user deal with failed updates
at some later date.
Problems:
- will all clients connect again at the same time? No.
- how would you determine the correct order of queued updates being
applied? Can't.
- how would you deal with failures? Is the user still there to deal
with it?
- Do they have to deal with every off-line update manually?
Even if it became read-only when the connection dropped you'd still
have to send all changes simultaneously to the client cached db and
the remote. I'm replicating data between clients and their web
site. I can guarantee this won't be fun to implement nor be out of
your hair in six months.
Yes, I see what you're saying. Managing update conflicts might be a
killer. I originally thought of this in terms of replicating data
from one persistence system to the other, didn't even consider using
this in a full blown multi-user, concurrent-update scenario. But
when John posted his question, I thought: "hey, that idea I had
could handle this!" I guess I have a tendency to run my big mouth
before thinking something through... In my defense, I put some
qualification in my original reply, I said:
Flor and Lachlan are exactly right, solving this in a general way
would require very inappropriate assumptions. But OCC patterns are
fairly common (and sometimes even required) in fields like healthcare,
sales, and manufacturing because you can make domain assumptions that
are perfectly valid and write domain-specific conflict resolution rules.
I wouldn't want to dissuade the OP from going this route if he needs
to. For example we have an app deployed on Symbol devices that's
heavily used by airport workers...the devices are cellular but
connectivity is far from guaranteed as they move through tunnels,
aircraft, jetways, etc. Occasionally connected is the /only/ way a
system like that is viable, but we can make very reasonable
assumptions like "only one agent can push a wheelchair at a time" and
"if an agent received a dispatch request, he must be online to accept
it".
My main concern with trying this with WebObjects would be, as others
have said, trying to sync the persistence layers. Even if you could
get it to work it would be horribly inefficient. In every system
we've ever built like this we've handled the data sync at the database
level through either OTS or custom replication. Hypothetically this
approach should work with WO...the clients always write locally and
the sync is database-to-database whenever a connection becomes
available.
HTH,
John
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden