I don't think the spec prohibits multiple dbs in the backend, so my concern is to not difficult it
Quoting Joerg von Frantzius <[EMAIL PROTECTED]>: > Hello Erik, > > this seems to be connected to thread Transaction Manager and JCA > <http://www.jpox.org/servlet/forum/viewthread?thread=4099>, where it > seems you proposed to associate a single PersistenceManagerFactory with > multiple DBs. As a PMF only has properties to connect and authenticate > with a single DB (URL, username/pw), I think the spec implicitly defines > that a PMF can be connected to a single DB only. > > So it seems to me your question implies some fundamental conceptual change? > > Regards, > Jörg > > Erik Bengtson wrote: > > Craig, I understand that server means the backend database server. what it > we > > have multiple backend db servers? > > > > Use case with multiple dbs: > > > > SELECT FROM db1.classA WHERE classA.time > datetime() && classB.time > > > datetime() VARIABLES db2.classB > > > > The first datetime() is evaluated by db1, while the second by db2. > > > > Quoting Craig L Russell <[EMAIL PROTECTED]>: > > > > > >> Here is a proposal to add the ability of a user to get the time at > >> the server in a portable way. > >> > >> This should allow an application to avoid time skew by using the time > >> as seen by a single source, the server to which the > >> PersistenceManagerFactory is connected. > >> > >> <proposed> > >> 11.1 > >> ... > >> ServerTimeZoneID: the time zone ID of the server to which this > >> PersistenceManagerFactory is connected, for use with the > >> PersistenceManager method getServerDate > >> If ServerTimeZoneID is specified, the value must correspond to a > >> valid time zone ID as returned by TimeZone.getAvailableIDs(). The > >> implementation uses the ServerTimeZoneID to implement the > >> getServerDate method. If ServerTimeZoneID is not specified, the > >> implementation might use proprietary methods to determine the time > >> zone in which the server is located. If ServerTimeZoneID is not > >> specified, and the implementation cannot or does not use proprietary > >> methods to determine the server time zone, then the default time zone > >> ID of the Java VM is used. > >> > >> 12.17 Server Date > >> java.util.Date getServerDate(); > >> > >> Time skew is a phenomenon in which machines connected together in > >> client/server configurations might have clocks that are not perfectly > >> synchronized, and the time as seen by different clients might differ. > >> In order for the application to avoid time skew, this method can be > >> used to acquire a Date instance corresponding to the UTC Date as seen > >> by the server. Clients using this method can order their operations > >> according to a single time source. > >> Implementations use the setting of the server time zone to prepare a > >> Date instance that represents UTC time on the server. > >> </proposed> > >> > >> Craig Russell > >> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo > >> 408 276-5638 mailto:[EMAIL PROTECTED] > >> P.S. A good JDO? O, Gasp! > >> > >> > >> > > > > > > > > > > > > > >
