Joerg, > How do you want to configure multiple database connections per PMF > without extending the spec?
Agreed, this has to discussed/specified in JPOX. After completed the implementation, I see this as a potential feature to be proposed to JDO standard Quoting Joerg von Frantzius <[EMAIL PROTECTED]>: > Erik Bengtson wrote: > > I don't think the spec prohibits multiple dbs in the backend, so my > > concern is to not difficult it > > > The spec allows for multiple DBs in the backend, with a single PMF for > each of them (or what backend were you referring to?) > > How do you want to configure multiple database connections per PMF > without extending the spec? > > 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! > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > >>> > >>> > >> > > > > > > > > > > > > > >
