axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ajith Ranabahu" <ajith.ranab...@gmail.com>
Subject Re: Representing a Birthday in a distributed scenario
Date Fri, 11 Jul 2008 07:00:30 GMT
Hi,
I may be thinking of this in an oversimplified way but here is what I see

1. XSD Date provides the explicit addition of timezone data (See [1]).
If the XML instance includes a fully qualified timezone data then
would it not provide enough details (for anything such as an audit
trail)  to reconcile ?

2. Use of a calendar object in between could be used to fetch
timestamp information (supposing that the database server and the JVM
are running in the same timezone or JDBC somehow figures out to read
the correct timezone information from the database).IMHO even if we
instantiate a calendar object, the seed for the calendar would be the
Date object coming from JDBC (and hence does not make a difference if
we change the DAO layer). If you are thinking of the DAO and the rest
of the code running in separate VMs (I'm not sure whether that is even
possible. Are you thinking of an RMI sort of thing where objects are
passed through some means in between VM's ?) I would say the chances
are pretty slim of that happening [ Even if it happens how frequent
would it be for the VM's to be different timezones ? If anyone tries
such an exotic setup they should suffer the consequences :) ]

3. Using anything other than standard Java type (specially when its a
well established norm) is not advisable. IMHO the use of util.Date or
sql.Timestamp are pretty common and well known (and they do provide
ways of getting the timezone and other information. It may not be very
straighforward. Anyone who's not happy are free to use something like
Joda and stay out of cumbersome code). My opinion is that we should
stick to standard types as far as possible at the interface level to
make things simple for the users. For example XMLbeans has its own set
of classes to represent all XMLtypes but what I see is that it makes
the generated interfaces crowded (same thing can happen with a DAO
framework if we put lot of stuff). IMHO we should touch ADB (with
respect to this issue) only if the time functionality is absolutely
broken.



Ajith


[1] http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dateTime


On Fri, Jul 11, 2008 at 1:41 AM, Sanjaya Karunasena <sanjayak@yahoo.com> wrote:
> I am happy! Finally there is some one who is interested in this topic :-)
>
> The problem I am highlighting is not about level of accuracy (where you have
> to bring in Lamport Ordering). Its about a design flaw in the Java API which
> could lead to a data integrity issues. Here is one example;
>
> For auditing/tracing purposes, a Timestamp is stored in a database. Now when
> I request an audit trail from some "Audit" service it will have to go to the
> database retrieve those values and send them as XML. Let's say the service
> is using JDBC to access the database. JDBC Timestamp extends Java util Date.
> However, XSD type mapping for Timestamp should be a DateTime and DateTime in
> Java should be a Calendar. So from the DAO layer it must be instantiating a
> Calendar instance to send it to the next layer (You have to live with mili
> second accuracy of course).
>
> In the SimpleTypeMapper we use SimpleDateFormat which internally use another
> Calendar instance (that's the Java implementation). If every thing happens
> within the same JVM we should be OK unless, we hit the window where the
> daylight saving change occurs. If we use the original Calendar instance
> which passed in to SimpleTypeMapper, I think we can avoid this issue.
>
> But I guess you get my point. Java's thinking on representing date and time
> is not comprehensive enough to handle these use cases and that's why we have
> write code to work around that. As we all know, for many enterprise systems
> data integrity is very critical. A good design can avoid issues by design,
> but yet be simple.
>
> I can empathize your resistance to inheriting another library. But then
> discuss how we can accurately represent these design elements.
>
> /Sanjaya
>
> ----- Original Message ----
> From: Eran Chinthaka <eran.chinthaka@gmail.com>
> To: axis-dev@ws.apache.org
> Sent: Friday, July 11, 2008 9:43:02 AM
> Subject: Re: Representing a Birthday in a distributed scenario
>
> Hi Sanjaya,
>
> I agree with your point here. Also as you might already know, one of the
> best known ways to represent times within a distributed system is to use an
> implementation of Lamport clocks. Also these distributed clocks are really
> useful when the system has large number of nodes.
>
> But my question is no one had ever complained about these time problems. And
> also if we can do this using timezone information (which I am yet to find
> out), why bother introduce new libraries in to that?
> We can find loads of things build around, java foundation classes, which
> claims to improve basic java functionality. If the current thing is working,
> 99% of the time why bother worrying about it.
>
> I can still remember what Sanjiva and Glen wrote on the white board during
> the last day of first Axis2 summit. We always should KISS and adhere to
> YAGNI, which I liked a lot.
>
> Please note that, I appreciate your suggestion and understand what your
> point is. But making it a first class citizen by putting those in to ADB,
> hmm ... I don't think I will agree to that.
>
> On Tue, Jul 8, 2008 at 1:47 AM, Sanjaya Karunasena <sanjayak@yahoo.com>
> wrote:
>>
>> Hi All,
>>
>> Usually to represent some thing like a Birthday java Date class is used.
>> However, it internally make use of a Calendar instance in most of the
>> operations.
>> This means unless we send timezone information in a Web Service request
>> with the birthday, there is a time window, when the client and the server is
>> in two different timezones, the day get represented inaccurately.
>>
>> I came across this library (http://joda-time.sourceforge.net) which
>> doesn't suffer from such design flaws.
>> (http://joda-time.sourceforge.net/key_partial.html)
>>
>> Thoughts? Probably we need to fix ADB to handle this.
>>
>> /Sanjaya
>>
>>
>
>
>
> --
> With Mettha,
> Eran Chinthaka
>
> --------------------------------------------------------------------
> Health is the greatest gift; contentment is the greatest wealth; trusting is
> the best relationship; nirvana is the highest joy. - Dhammapada
>



-- 
Ajith Ranabahu

Reading, after a certain age, diverts the mind too much from its
creative pursuits. Any man who reads too much and uses his own brain
too little falls into lazy habits of thinking - Albert Einstein

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


Mime
View raw message