Option 3 is a good options as well. It would mitigate any schema differences for you and would allow for a simple user interface allowing end-users to migrate data as needed. Although you can not currently have a single PU connect to 2 different databases you could duplicate your PU and connect to System A with that duplicated PU.
--Gordon
-----Original Message-----
From: Romanowski, Tim [mailto:tim.romanowski_at_lmco.com]
Sent: Monday, April 30, 2007 11:55 AM
To: users_at_glassfish.dev.java.net
Subject: RE: Connect to PU at runtime? How to merge data from two
different PUs.
Thanks for your response.
The database is 10g. Would like to use it with 9i as well. The reason I
thought it might be better to do it in the app server, was so that the user
could dynamically select which data to transfer by checking off some boxes,
using a few pulldowns, etc. (that is, not require a user to write sql). I
can imagine that hooking up a web interface to whatever is done via the
RDBMS might not be too bad. Is there a particular path you suggest I follow
using Oracle?
Tim
-----Original Message-----
From: Wayne Fay [mailto:waynefay_at_gmail.com]
Sent: Monday, April 30, 2007 10:44 AM
To: users_at_glassfish.dev.java.net
Subject: Re: Connect to PU at runtime? How to merge data from two different
PUs.
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
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
For additional commands, e-mail: users-help_at_glassfish.dev.java.net