Maybe I got something wrong here, but don't we run into a whole lot of
other questions here? Like, when we execute a query, what DB will it be
run on? When invoking operations on a PersistenceManager from a PMF with
multiple databases, which DB will the resulting SQL be sent to?
Erik Bengtson wrote:
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!
