Disconnected operation ?

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Rainer Duffner - 25 Nov 2004 23:30 GMT

Hi,

I've got a question:
If I wanted to design a system for data-entry from various remote
locations, I'd normally build/use whatever 2- or 3-tiered system came to
mind - PHP, application-servers - whatever.
But when the link between the remote-site and the central database is
down, work stops at the remote site.
As this article puts it nicely, "it's like the 1960s".

This article is about "The Time Has Come for the Decentralized
Application Architecture".
But it fails to mention any products at all..

Does anybody have an idea ?
Ideally, I'm really looking for something 3-tier'ish-able, if you excuse
the word.

cheers,
Rainer

Reply to this Message

Rainer Duffner - 25 Nov 2004 23:31 GMT

> Hi,
>
> As this article puts it nicely, "it's like the 1960s".

This article, really:

http://www.devx.com/dbzone/Article/10993/0/page/1

Sorry for the confusion.

cheers,
Rainer

Reply to this Message

Christopher Browne - 26 Nov 2004 01:23 GMT

> I've got a question:
> If I wanted to design a system for data-entry from various remote
[quoted text clipped - 11 lines]
> Ideally, I'm really looking for something 3-tier'ish-able, if you
> excuse the word.

This seems an example of a "use case" for things like IBM MQSeries or
its ilk...

But reality is that the guy that wrote the article is from a company
called PeerDirect, who (surprise, surprise) are in the business of
selling a replication engine called _Peer Direct Replication Engine_.

It's compatible with some versions of Oracle, Microsoft SQL Server,
DB2, and PostgreSQL.

Signature

select 'cbbrowne' || '@' || 'ntlug.org';
http://www3.sympatico.ca/cbbrowne/unix.html
Editing is a rewording activity.
-- Alan Perlis
[And EMACS a rewording editor. Ed.]

Reply to this Message

Rainer Duffner - 26 Nov 2004 03:29 GMT

>> I've got a question:
>> If I wanted to design a system for data-entry from various remote
[quoted text clipped - 14 lines]
> This seems an example of a "use case" for things like IBM MQSeries or
> its ilk...

When I did some research before posting, messaging-systems appeared then
and now in google-search results.
But nothing specific.
And I know even less about messaging-systems in general, much less about
MQ-series, so I can hardly decide if this is a vital solution.

> But reality is that the guy that wrote the article is from a company
> called PeerDirect, who (surprise, surprise) are in the business of
> selling a replication engine called _Peer Direct Replication Engine_.

OK, but he managed not to let that drop in the article ;-)

> It's compatible with some versions of Oracle, Microsoft SQL Server,
> DB2, and PostgreSQL.

OK.
I must admit that this is really a kind of homework for what is probably
going to be some kind of assessment-center for a job I've applied - they
sent me a "show case" in advance to "think over". The show case didn't
mention disconnected operation of course, but if you have 10 location
around the country and want to expand to Eastern Europe, it seems pretty
silly not to have some kind of fall-back solution. OR a fall-back
solution more advanced than pen- and paper.
The details of all this are really beyond my skillz - I'm more into
security - but security is also about availability and so this is a
natural concern.

Thanks a lot.

cheers,
Rainer

Reply to this Message

Christopher Browne - 26 Nov 2004 16:58 GMT

>>> I've got a question:
>>> If I wanted to design a system for data-entry from various remote
[quoted text clipped - 40 lines]
> security - but security is also about availability and so this is a
> natural concern.

What they're providing is of some value, for sure. If you have a
bunch of not-perfectly-well-connected sites, it's valuable to
replicate data between them, even if some of it doesn't take place in
a particularly timely way.

What isn't clear is how they deal with "conflict resolution," that is,
if two sites generate conflicting data.

That would happen, for instance, if:

a) Two sites issue an invoice with the same ID number. That is
likely to be avoidable by having distinct sequences at different
sites.

b) Two sites issue different updates to a customer record. That
isn't so easily resolved.

What happens when those conflicts happen is pretty important. Some
distributed systems fail until someone breaks the conflict manually.

If you have a PalmPilot, you'll find that it copes with these kinds of
situations by making up two records, and expecting the user to resolve
the conflict by hand.

If there are particular sorts of identifiable conflicts that you can
'expect' beforehand, you can perhaps code an automatic conflict
resolution for the. Unfortunately, you probably won't know what
conflicts will pop up until after they happen :-(.

Signature

"cbbrowne","@","ntlug.org"
http://www.ntlug.org/~cbbrowne/linux.html
Black holes result from God dividing the universe by zero.

Reply to this Message

Jerry Gitomer - 26 Nov 2004 03:06 GMT

> Hi,
>
[quoted text clipped - 16 lines]
> cheers,
> Rainer

Hi Rainer,

You don't need any special software products. When the
connection drops your remote sites can be programmed to sense
the outage and then write to a sequential file. If you have a
local copy of the database you can completely validate the data
entry, but until the connection is re-established you cannot
verify that a transaction can be completed. When the
connection is restored run a batch load of the sequential file
and, in the event any transactions cannot be completed, notify
the person who entered the data.

It isn't very fancy or sophisticated, but then it isn't very
expensive to implement when compared to the cost of full
replication and synchronization.

HTH

Signature

Jerry Gitomer

Reply to this Message

Rainer Duffner - 26 Nov 2004 03:35 GMT

>> Hi,
>>
[quoted text clipped - 22 lines]
> connection drops your remote sites can be programmed to sense
> the outage and then write to a sequential file.

Hm. So this is really done at the application-level, right ?

> If you have a
> local copy of the database you can completely validate the data
[quoted text clipped - 3 lines]
> and, in the event any transactions cannot be completed, notify
> the person who entered the data.

I have some difficulty believing that this really works "in the field",
but this may depend on the exact design and implementation of the
application.

> It isn't very fancy or sophisticated, but then it isn't very
> expensive to implement when compared to the cost of full
> replication and synchronization.

Most probably, yes.
Even more so, if you think of MQ-series and company.
"If you have to ask for the price, it's probably too expensive for you
anyway"

cheers,
Rainer

Reply to this Message

Jerry Gitomer - 26 Nov 2004 18:47 GMT

>>> Hi,
>>>
[quoted text clipped - 24 lines]
>
> Hm. So this is really done at the application-level, right ?

Yes. The least expensive solution is to put a switch in the
program that writes to your database. If the switch is set
write to a sequential file.

>> If you have a
>> local copy of the database you can completely validate the
[quoted text clipped - 8 lines]
> the field", but this may depend on the exact design and
> implementation of the application.

Conceptually this can be done by having a switch in the data
entry program. If the switch is set read the input from the
sequential file instead of from the keyboard and report errors
to a file as well as the screen. (Just in case there are so
many errors that they would roll off of the screen.)

>> It isn't very fancy or sophisticated, but then it isn't very
>> expensive to implement when compared to the cost of full
[quoted text clipped - 7 lines]
> cheers,
> Rainer

Signature

Jerry Gitomer

Reply to this Message