Re: resent message from yesterday....

["Robert J. Lebowitz" <lebowitz@xxxxxxxxxxxxxx>]

> Just a thought - it will be more difficult to use this low level engine
> API while the database is live and able to deal with JDBC connections.
> What are you intending to do?  Periodically pull out chunks of data from
> tables and mirror the data on a remote sites?  Why not work at the top
> level, cache the JDBC interaction and replicate to the remote server?
> The copying of data at the lowest level while live will be tricky
> because the engine may be managing multiple versions of the database
> over concurrent transactions.

The synchronization scheme I'm looking at uses triggers that save
updates/deletes/inserts in a specially created database.  My thought was
that since you're already going to the trouble of creating some kind of
(presumably) serialized data record representing a row's worth of data, it'd
be easier to just "grab" the whole serialized fragment of data and send it
on to the remote server, rather than try deserialize and reserialize the
data again.  However, you've made a valid point; a server will be in
operation, and it might be simpler to devise a system using the JDBC API.
There are going to be network latency effects anyways, the whole thing is
asynchronous.

> I'd vote for XML over HTTP.  It seems a little strange to me to run a
> replication service that tunnels over HTTP.  I suppose it all depends on
> your intended audience.

XML would certainly be easier to "debug", and given the JDOM library, it's a
lot easier to work with in Java than in some languages.  Okay... I'll work
from there!

Thanks for the feedback.  The datapump seems to be working fine ... do you
have a place on your site for contributed software?



---------------------------------------------------------------
Mckoi SQL Database mailing list  http://www.mckoi.com/database/
To unsubscribe, send a message to mckoidb-unsubscribe@mckoi.com