[CSHARP-770] Make Server time available through Collection / Server objects Created: 30/Jun/13  Updated: 20/Mar/14  Resolved: 01/Jul/13

Status: Closed
Project: C# Driver
Component/s: None
Affects Version/s: 1.6
Fix Version/s: None

Type: Improvement Priority: Minor - P4
Reporter: Curt Mayers Assignee: Sridhar Nanjundeswaran
Resolution: Done Votes: 0
Labels: multiuser, sequencing, server, time, timestamp
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All



 Description   

It would be useful if the driver were able to return the database server's current time as a DateTime. Counting on a client machine's internal clock is unreliable, and there are many cases where a single, definitive time source is much more appropriate

Possible uses:
Create / update timestamps in records.
Calculation of elapsed time since a recorded datetime
Sequencing incoming records coming from multiple client machines
Rationalizing updates coming from different time zones.

Where machines are clustered, this call should always be satisfied from the "primary" machine, or arbiter.



 Comments   
Comment by Curt Mayers [ 09/Jul/13 ]

I'll do that.

Thanks for your patience.

Curt

On Fri, Jul 5, 2013 at 3:20 PM, Sridhar Nanjundeswaran (JIRA) <

Comment by Sridhar Nanjundeswaran [ 05/Jul/13 ]

Hi Curt,
Thanks for your comments and patience. IMHO this is not a feature that should be provided by the driver without support from the database server. I would recommend filing a core server ticket. We can then link this ticket to the core server ticket.

Comment by Curt Mayers [ 02/Jul/13 ]

The point is not to get an accurate time, it's to get a *consisten*t time.

I'm sure that you are well aware that--in all but a web or online service
scenario--control of client machines is not within the developer's hands,
and is out of his control. In fact, the *only *thing that clients will
have in common, in many situations is a connection to the server. They
may sit in different organizations, in different timezones, on different
platforms, etc.

That is why every commercial database engine on the market has a way of
retrieving the server's time, and/or a set of tokens or functions for
inserting the current time into a record.

You can certainly make it a requirement of cluster configuration that the
machines share a common times server, or designate a single machine as the
reference. But the idea that you can't account for differing network
latencies, or differences among machines within a service cluster (which is
at least potentially under someone's controls) are secondary to the need
for a definitive time source.

I hope you'll think about this some, because it would solve a lot of
potential problems, and do it in the most straightforward, consistent, and
uniform way available.

Thanks,
Curt

On Tue, Jul 2, 2013 at 4:22 PM, Sridhar Nanjundeswaran (JIRA) <

Comment by Sridhar Nanjundeswaran [ 02/Jul/13 ]

Hi Curt,
You do need NTP setup for at least the machines that are part of the MongoDB Cluster. Hence if you extend this to the client machine, you can get the time from the client locally as opposed to going to the server to get it.

Even if you could get the server time how would you account for network delay to find the actual time?

To clarify your point 4
for replica sets there is no single arbiter/master. Each machine is equivalent to another. If you are thinking about the mongodb arbiter there is nothing that stops you from having more than one arbiter in a replica set cluster.
In the case of the sharded cluster, you could assume the source of truth is a config server but there are 3 of them. Which would you choose?

In both these cases we are still not considering the case of authenticated clusters where you may not have access to some "canonical database" to provide such a functionality. Hope this clarifies why we recommend using NTP for getting time and there is no direct core server support for this

Comment by Curt Mayers [ 01/Jul/13 ]

I don't think this is an adequate solution:

1. The time resolution of multiple machines subscribing to a time server is not accurate enough for many of the needs that I suggested that a server time would be useful for.

2. Most of the use cases I suggested (e.g. filling in "last updated date" in records) will take place on client machines; and no one has sufficient control over software client apps to ensure that all parties not only subscribe to a NTP server, but the same one, and with a common resolution.

3. Even if all of the machines participating in a Mongo cluster DID use a common time server, it means that the developer must design a second channel, and a separate service and server to pass time information back from the server. Every other enterprise database with which I'm familiar has a way of referencing the server time for such needs.

4. In the two cases that you suggested in points 2 and 3, you return the case of the arbiter in a cluster set, or the current primary in a replica set.

Comment by Sridhar Nanjundeswaran [ 01/Jul/13 ]

The correct way of doing this is to set up NTP on your database node(s) and client/app server machines. This way the clocks are in sync and you can use the time from your client/app server.
The problem with server time is, what is server time in a cluster?
1) In case of a single standalone server it is just that server's time. Even in this case since you do not know how long the query took, you do not know what is the actual server time
2) In the case of replica sets, which member's time are we talking about? Simple assumption is that it is the primary's. What if there is no primary when you request server time?
3) In the case of a sharded cluster, is server time, the time of the mongos you are connected to?

Generated at Wed Feb 07 21:37:46 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.