Re: JavaClient offline storage / replication
Re: JavaClient offline storage / replication
- Subject: Re: JavaClient offline storage / replication
- From: Lachlan Deck <email@hidden>
- Date: Thu, 16 Apr 2009 07:32:41 +1000
On 16/04/2009, at 1:51 AM, Stamenkovic Florijan wrote:
On Apr 15, 2009, at 11:24, John Huss wrote:
We're considering using JavaClient for some new projects and one of
the big features we want is the ability to run offline by caching
database from the server's DB and storing any modifications locally
until the server is online again. How would you approach this? Is
it possible to use the same EOModel and use EOF on the client to
save the data locally?
Your way: no. You are not allowed to do this. You can only
distribute the client-side libs in your client app, and those do not
contain the functionality to connect to whichever data-source
(EOAccess).
Here are some thoughts that I had on this subject in the past...
Basically two ideas occurred to me for handling this.
1. Serializing an EOEditingContext. EOEC implements Serializable.
And if you think about it, it might be! However, in a practical JC
scenario this does not really do you any good. An EC will want a
parent object store, and without a connection to the WO server, you
can't give it one. And even if you somehow manage to hack this, as
soon as a fault gets fired, and you don't have a connection to your
data source, you're screwed.
2. Now, this is a pretty big idea, on my to-do-in-the-coming-5-years
list. It comes down to implementing:
a) Local persistence support for JBND
b) A further elaboration of non-persistence-specific relational
concepts for JBND
c) JBND code that focused on migrating data from one persistence
system to another
d) An "AppKit" architecture that is JBND based and focuses on
writing client apps that are capable of dealing with multiple
persistence sources, and to switch connections between them
dynamically, or at least have multiple connections in parallel
This would solve your problem,
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.
with regards,
--
Lachlan Deck
_______________________________________________
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