Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

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

 
Raja Stal
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • 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
 
Rok Štelcer
Ranch Hand
Posts: 101
  • Mark post as helpful
  • send pies
  • 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
 
Steve Luke
Bartender
Posts: 4181
22
IntelliJ IDE Java Python
  • Mark post as helpful
  • send pies
  • 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)?
 
Ulf Dittmer
Rancher
Posts: 42972
73
  • Mark post as helpful
  • send pies
  • 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
  • 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: 4181
22
IntelliJ IDE Java Python
  • Mark post as helpful
  • send pies
  • 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
  • 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
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!