I'd personally prefer/suggest to do this from the database side, not
the application side. This problem has been solved by most RDBMS
systems and is pretty trivial on that side, while it sounds rather
nontrivial (to me at least) to make it work on the app server side
What database(s) are you running?
Wayne
On 4/28/07, Romanowski, Tim <tim.romanowski_at_lmco.com> wrote:
>
>
>
> I've been reading up Persistence Units and deployment, and have a few
> questions on the following scenario:
>
>
>
> Server A hosts application MyWebApp using Glassfish. My WebApp uses the JPA
> to persist its data to its own local database.
>
> Server B also hosts MyWebApp using Glassfish. Similarly, it persists its
> data to its own local database.
>
>
>
> Server B is rarely used, and does not hold that much data. In fact, it
> isn't even hooked up to the network very often. On the rare occasion that
> Server B is used, I would like to merge all OR some of the data from Server
> B's database back into Server A. The trick here, is that I would like to
> provide an 'automated' way to merge this data, so that an administrator on
> Server B can go to a webpage in the webapp, select which tables to transfer,
> click a link, and have the data saved to Server A's database.
>
>
>
> 1) I could use a web service to transfer the data, but that seems like it
> would be very inefficient.
>
> 2) Another option is to have MyWebApp on server B just call a script and
> dump the data to a file. But that means manually (or via script) merging
> that file back into the DB. I don't want to do that.
>
> 3) Lastly, what I really want to do (or is this bad?) is have Server B
> connect to Server A's datasource (keep in mine, both web apps have the same
> entity classes), and then use the POJO love from the JPA to get all entities
> from Server B and insert them into Server A's database. It wouldn't be a
> direct copy in the since I'd obviously be using two different EntityManagers
> to access a given table in both databases, but I could (worst case) insert
> each entity from Server B into Server A.
>
>
>
> Is there a slick way to implement number 3? My biggest problem is that
> neither server knows the OTHER server's database information (such as ip
> address) until runtime. From what I've read, I can't tell if it's possible
> to define a persistence unit's details at runtime, and even less likely, I
> wonder what the issue would be with trying to uses the same entity classes
> in a single web app (on a single server) to connect to two separate PUs.
> The idea is simple, have one app that connects to two identical databases,
> instantiate entities from one database and save them into another. The
> reason I want to do this automagically in the web app, is so I can perform
> some business logic on Server B's data before it is inserted into Server A.
> Is this a flawed approach? Any suggestions?
>
>
>
>
>
> Tim
>
>
>