• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Accessing a static method with the local variable of java.text.SimpleDateFormat by multiple threads

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I recently learnt that java.text.SimpleDateFormat class is not a thread-safe class. If that's the case, will a static method as below with a local variable of java.text.SimpleDateFormat is meant to be a Non-threadsafe?

static String getTimeStampAsString(TimeStamp ts) {

DateFormat df=new SimpleDateFormat("dd/MM/yyyy");

String s = df.format(new Date(ts.getTime()));

return s;


}

Using this above static method to format timestamp I am seeing corrupted dates in my web application. Any suggestions on how to improve this method will be appreciated.

Thanks
Stal
 
Ranch Hand
Posts: 101
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

You should synchronize the method call.
Thishow each caller would have to obtain a Class lock before entering.


Regards,
Rok
 
Bartender
Posts: 4179
22
IntelliJ IDE Python Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There is no thread-safety problem with the original code you posted, at least not associated with the SimpleDateFormat. Each thread makes a separate call to the getTimeStampAsString() method, and each time the method is called it creates a new SimpleDateFormat object. This object is independent for each method call, not shared between them so there is no chance of the object's data getting corrupted by multiple thread activity.

Note that Date (and thus your TimeStamp) are NOT thread safe, so if you re-use the same TimeStamp object in multiple Threads then that can cause corruption.

But chances are the problem lies someplace else. Exactly what does 'corruption' mean? Is this the code that is actually running on your web app (did you change to this code, restart the web app and then re-test)?
 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Rok Štelcer wrote:You should synchronize the method call.


No, that's not necessary, as Steve explained.
 
Raja Stal
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Steve,

My dates are getting corrupted with an inconsistent month and year. I have last_updated_date field where we are storing the current time stamp(using System.currentTimeMillis()) when we are creating the record in the database. This code has been in the application for a long time. But quite recently we have found the last_update_date field has future dates like 2015-11-02 or past date like 2001-11-02 etc.

Apart from this field, there are other date fields in the table where we are formatting and storing dates which are logically valid with with future dates.

Hope this helps to understand the problem.

thanks
Stal
 
Steve Luke
Bartender
Posts: 4179
22
IntelliJ IDE Python Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Without code, I don't think I can be much help. A few things I would watch for:
1) You don't do any 'date math' with the Date object itself, or the long that gets returned from getTime()
2) You don't inadvertently store the time as an int value rather than a long value
3) You server uses its own internal clock to generate time stamps (doesn't get it from clients) and its clock is properly set
4) The Time Stamps you get from your database are properly formatted (stored and retrieved appropriately for how you view them).

It is not inconceivable that a DB has a different idea as to how dates/timestamps should be stored, and that idea is in-appropriate for what Java expects. Read the docs for the commands you give the DB just to be sure that they are what you expect. Look at how the dates get added, how they get stored and how they get retrieved. Then compare that with the method Java uses to work with the dates.

 
Rok Štelcer
Ranch Hand
Posts: 101
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Ulf Dittmer wrote:

Rok Štelcer wrote:You should synchronize the method call.


No, that's not necessary, as Steve explained.


Yes, you're indeed correct ... ty.


Regards,
Rok
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic