You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Craig L Russell <Cr...@Sun.COM> on 2007/02/09 01:17:12 UTC
[DISCUSS} Server TimeZone
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:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: [DISCUSS} Server TimeZone
Posted by Joerg von Frantzius <jo...@artnology.com>.
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 <jo...@artnology.com>:
>
>
>> 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 <jo...@artnology.com>:
>>>
>>>
>>>
>>>> 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 <Cr...@Sun.COM>:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> 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:Craig.Russell@sun.com
>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>
>
>
>
>
Re: [DISCUSS} Server TimeZone
Posted by Erik Bengtson <er...@jpox.org>.
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 <jo...@artnology.com>:
> 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 <jo...@artnology.com>:
> >
> >
> >> 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 <Cr...@Sun.COM>:
> >>>
> >>>
> >>>
> >>>> 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:Craig.Russell@sun.com
> >>>> P.S. A good JDO? O, Gasp!
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >
> >
> >
> >
> >
> >
>
>
Re: [DISCUSS} Server TimeZone
Posted by Joerg von Frantzius <jo...@artnology.com>.
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 <jo...@artnology.com>:
>
>
>> 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 <Cr...@Sun.COM>:
>>>
>>>
>>>
>>>> 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:Craig.Russell@sun.com
>>>> P.S. A good JDO? O, Gasp!
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>
>
>
>
>
Re: [DISCUSS} Server TimeZone
Posted by Erik Bengtson <er...@jpox.org>.
I don't think the spec prohibits multiple dbs in the backend, so my
concern is to not difficult it
Quoting Joerg von Frantzius <jo...@artnology.com>:
> 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 <Cr...@Sun.COM>:
> >
> >
> >> 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:Craig.Russell@sun.com
> >> P.S. A good JDO? O, Gasp!
> >>
> >>
> >>
> >
> >
> >
> >
> >
> >
>
>
Re: [DISCUSS} Server TimeZone
Posted by Joerg von Frantzius <jo...@artnology.com>.
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 <Cr...@Sun.COM>:
>
>
>> 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:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>>
>>
>
>
>
>
>
>
Re: [DISCUSS} Server TimeZone
Posted by Erik Bengtson <er...@jpox.org>.
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 <Cr...@Sun.COM>:
> 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:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>