HASHMAP is it thread safe really?

Hi all,
I want to use the Hashmap class in my program but I need to know is it thread safe???
Thanks
ps where would I find out information like that?

I am just wondering what gave u the concept of thread safetyness.........Well its up to u how u make use of it for that matter even a simple program can be thread unsafe u know........ its only the implementation which matters So don't worry take my word and go ahead with that...the class by itself is threadsafe but do a proper implementataion.

Similar Messages

Are static nested classes thread-safe?

There doesn't seem to be any definitive answer to this. Given the following code, is it thread-safe?
public class SomeMultiThreadedWebController {
public HttpServletResponse someMethodToExecuteViaWebRequest(HttpServletRequest request) {
    simpleQueryBuilder("SELECT...").addParameter("asdf","asdf").createQuery(EMF.getEntityManager()).executeUpdate();
protected static class SimpleQueryBuilder {
         private String queryString;
         private Map<String, Object> params = new HashMap<String, Object>();
         public SimpleQueryBuilder(String queryString) {
              this.queryString = queryString;
         public SimpleQueryBuilder addParameter(String name, Object value) {
              params.put(name, value);
              return this;
         public Query createQuery(EntityManager em) {
              Query query = em.createQuery(queryString);
              for (Entry<String, Object> entry : params.entrySet()) {
                   query.setParameter(entry.getKey(), entry.getValue());
              return query;
    public static SimpleQueryBuilder simpleQueryBuilder(String queryString) {
         return new SimpleQueryBuilder(queryString);
}Forget whether or not someone would do this, as this is just an example. I'm really trying to get at whether or not the instance variables inside the static nested class are thread-safe. Thanks for any responses.

Hello,
I believe you understand what you're talking about, but you state it in a way that is very confusing for others.
Let me correct this (essentially, incorrect uses of the terminology):
I agree that thread-safe or not is for an operation, for a member, it has some sort of contextual confusion.
Member has a much broader meaning in the [Java Language Specification|http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.4] . Even "class member" applies to both an attribute, a method, or an inner class or interface.
I think you mean "member variable" of a class (aka "attribute" or "field"). By the way, static or not is irrelevant to the rest of the discussion.
For an operation or a member, if there's only one thread could access it atomically in one moment, we could call it thread-safe.Mmm. I was tempted to say yes (I'm reluctant to commit myself). With an emphasis on "_The encapsulating class_ makes this member's usage thread-safe".
Still, just synchronizing each operation on a member is not enough to make all usages "thread-safe":
Consider a java.util.Vector: each add/get is synchronized, so it is atomic, fine.
However if one thread adds several values, let's say 3, one by one, to a vector that initially contains 0 values, and another thread reads the vector's size() (another properly synchronized method), the reader thread may witness a size anywhere among 0, 1, 2, 3, which, depending on the business logic, may be a severely inconsistent state.
The client code would have to make extra work (e.g. synchronizing on the vector's reference before the 3 adds) to guarantee that the usage is thread-safe.
Thus any synchronized method(With the limit stated above)
or immutable member (like primitive type) are thread-safe.
Additionally for a member, if it's immutable, then it's thread-safe. You mean, immutable primitive type, or immutable object. As stated previously, an immutable reference to a mutable object isn't thread-safe.
a static final HashMap still have thread-safe issue in practice because it's not a primitive.The underlined part is incorrect. A primitive may have thread-safety issues (unless it's immutable), and an object may not have such issues, depending on a number of factors.
The put, get methods, which will be invoked probably, are not thread-safe although the reference to map is.Yes. And even if the put/get methods were synchronized, the client code could see consistency issues in a concurrent scenario, as demonstrated above.
Additional considerations:
1) read/write of primitive types are not necessarily atomic: section [ §17.7 of the JLS|http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.7] explicitly states that writing a long or double value (2 32-bits words) may not be atomic, and may be subject to consistency issues in a concurrent scenario.
2) The Java Memory Model explicitly allows non-synchronized operations on non-volatile fields to be implemented in a "thread-unsafe" way by the JVM. Leading way to a lot of unintuitive problems such as the "Double-Checked Locking idiom is broken". Don't make clever guess on code execution path unless you properly synchronize access to variables across threads.
Edited by: jduprez on Mar 4, 2010 9:53 AM

Hashtable really thread safe or is there a bug in it ?

Hashtable is said to be thread-safe, so I think it should be true.
So I just want someone to tell me what is wrong with my following observation:
I downloaded the source code of jdk 1.3.1 and read the file Hashtable.java, that contains the implementation code of Hashtables.
Lots of methods (like get(), put(), contains(), ...) are declared public and synchronized. So far, all is good.
But the function size() is defined as follows:
public int size() {
return count;
where count is an instance variable defined as follows:
* The total number of entries in the hash table.
private transient int count;
As the function size() is not synchronized, it can retrieve the value of "count" when another method is in the process of updating it.
For instance, the method put() (that is synchronized) increments the variable "count" with this instruction:
count++;
But we know that operation on variable of type "int" are atomic, so this issue doesn't harm the thread safety of the code.
But there is another issue with multithreading, that deals with caching of data in the working memory of each thread.
Suppose the following scenario:
1) Thread A calls method size(). This method reads the value of "count" and put it in the working memory of thread A.
2) Thread B calls method put(). This method increments "count" using instruction "count++".
3) Thread A calls method size() again. This method reads the value of "count" from the working memory of the thread, and this cached value may not be the updated value by thread B.
As size() is not synchronized, or "count" is not declared "volatile", multiple threads may retrieve stale value, because the content of the thread working memory is not in sync with main memory.
So, here I see a problem.
Is there something wrong in this observation ?
But

Is there something wrong in this observation ?Unfortunately not, as far as I can tell.
Recent analysis of java's synchronized support has revealed the danger in such unsynchronized code blocks, so it may have been a simple case that it wasn't realised that size is not thread-safe.
If this is an issue, use Collections.synchronizedMap - in Sun's JDK 1.3, at least, all of the methods are synchronized, except for iterators.
Regards,
-Troy

Thread-safe design pattern for encapsulating Collections?

Hi,
This must be a common problem, but I just can't get my head around it.
Bascially I'm reading in data from a process, and creating/updating data structuers from this data. I've got a whloe bunch of APTProperty objects (each with a name/value) stored in a sychronized HashMap encapsulated by a class called APTProperties. It has methods such as:
addProperty(APTProperty) // puts to hashmap
getProperty(String name) // retreives from hashmap
I also want clients to be able to iterate through all the APTProperties, in a thread safe manner . ie. they aren't responsible for sychronizing on the Map before getting the iterator. (See Collections.synchronizedMap() API docs).
Is there any way of doing this?
Or should I just have a method called
Iterator propertyIterator() which returns the corresponding iterator of the HashMap (but then I can't really make it thread safe).
I'd rather not make the internal HashMap visible to calling clients, if possible, 'cause I don't want people tinkering with it, if you know what I mean.
Hope this makes sense.
Keith

In that case, I think you need to provide your own locking mechanism.
public class APTProperties {
the add, get and remove methods call lock(), executes its own logic, then call unlock()
//your locking mechanism
private Thread owner; //dont need to be volatile due to synchronized access
public synchronized void lock() {
while(owner != null) {
wait();
th = Thread.currentThread();
public synzhronized void unlock() {
if(owner == currentThread()){
owner = null;
notifyAll();
}else {
throw new IllegalMonitorStateException("Thread: "+ Thread.currentThread() + "does not own the lock");
Now you dont gain a lot from this code, since a client has to use it as
objAPTProperties.lock();
Iterator ite = objAPTProperties.propertyIterator();
... do whatever needed
objAPTProperties.unlock();
But if you know how the iterator will be used, you can make the client unaware of the locking mechanism. Lets say, your clients will always go upto the end thru the iterator. In that case, you can use a decorator iterator to handle the locking
public class APTProperties {
public Iterator getThreadSafePropertyIterator() {
private class ThreadSafeIterator implements Iterator {
private iterator itr;
private boolean locked;
private boolean doneIterating;
public ThreadSafeIterator(Iterator itr){
this.itr = itr;
public boolean hasNext() {
return doneIterating ? false : itr.hasNext();
public Object next() {
lockAsNecessary();
Object obj = itr.next();
unlockAsNecessary();
return obj;
public void remove() {
lockAsNecessary();
itr.remove();
unlockAsNecessary();
private void lockAsNecessary() {
if(!locked) {
lock();
locked = true;
private void unlcokAsNecessary() {
if(!hasNext()) {
unlock();
doneIterating = true;
}//APTProperties ends
The code is right out of my head, so it may have some logic problem, but the basic idea should work.

Thread safe ?

Hi
This code is currently running on my companys server in a java class implementing the singleton pattern:
public static ShoppingAssistant getInstance() {
    if (instance == null) {
        synchronized (ShoppingAssistant.class) {
            instance = new ShoppingAssistant();
    return instance;
}1 Is there really a need for synchronizing the method?
2 If you choose to synchronize it. Why not just synchronize the whole method?
3 Is this method really thread safe? Is I see it a thread A could be preempted after checking the instance and seing that it is null. Thereafter another thread B could get to run, also see that instance is null and go on and create the instance. Thereafter B modifies some of the instance�s instance variables. After that B is preempted and A gets to run. A, thinking instance is null, goes on and create a new instance of the class and assigns it to instance, thus owerwriting the old instance and creating a faulty state.
By altering the code like this I think that problem is solved although the code will probably run slower. Is that correct?
public static ShoppingAssistant getInstance() {
    synchronized (ShoppingAssistant.class) {
        if (instance == null) {
            instance = new ShoppingAssistant();
}Regards, Mattias

public class Singleton {
private static final instance = newSingleton();
public static Singleton getInstance() {
return instance;
}This seems like it's so obviously the standard
solution, why do
people keep trying to give lazy solutions? Do they
expect it to be
more efficient that this?I can see one possible performance gains with a lazy solution:
If you use something else in that class (besides getInstance()), but don't use getInstance, then you don't take the performance hit of instantiating the thing.
Of course, this is dubious at best because how often do you have other static methods in your singleton class? And not use the instance? And have construction be so expensive that a single unnecessary one has a noticeably detrimental impact on your app's performance?

Thread-safe Singleton

Hi,
I want to create a thread safe singleton class. But dont want to use the synchronized method or block. One way i could think of was initializing the object in static block. This way the instance will be created only once. But what if instance becomes null after some time. How will it get initialized again. Can anyone help me in creating a thread safe singleton class.
Also i would really really appreciate if some one can point me to a good tutorial on design patters, I searched on google.. Found many.. But not finding any of them satisfying.
Thanks

tschodt wrote:
Balu_ch wrote:
kilyas wrote:
Look into the use of volatile instead of synchronized, however the cost of using volatile is comparable to that of synchronizingCan you please explain in detail Google can.
Google ( [java volatile vs synchronized|http://www.google.com/search?q=java+volatile+vs+synchronized] ).
Hi, I think we need to use both (volatile and synchronized). Can some please explain how "volatile" alone can be used to ensure thread safe singleton? Below is the code taken from wikipedia
public class Singleton {
   // volatile is needed so that multiple thread can reconcile the instance
   // semantics for volatile changed in Java 5.
   private volatile static Singleton singleton;
   private Singleton()
   // synchronized keyword has been removed from here
   public static Singleton getSingleton(){
     // needed because once there is singleton available no need to acquire
     // monitor again & again as it is costly
     if(singleton==null) {
       synchronized(Singleton.class){
          // this is needed if two threads are waiting at the monitor at the
          // time when singleton was getting instantiated
          if(singleton==null)
          singleton= new Singleton();
   return singleton;
}

Thread safe RMI

Thread safe RMI.
My RMI server provides clients with the ability to CRUD data but in order to manage concurrency I did the following.
1stly I would like to understand correctly the issues of RMI server objects....
It is my understanding that RMI server can cater for eg 100 clients by spawning 100 threads at random for each client. This process is not managed (thread wise) and the result is that 20 clients wishing to update record A can do so at will? Various steps can be taken from what I gather...
a) Synchronise (expensive)
b) implement a lock manager.
The step I have taken is include a lock manager and I have ensured that all locking an unlocking occur in a singleton server object that manages all sensitive data CRUD operations. Now I use a lock manager but I would like to know what happens if for eg the 1st RMI client dies and has its thread blocking
all other threads from locking the same record? Does the thread die with the client or is there a counter measure for this? The obvious answer that comes to mind is Object.wait() inside the lock manager?
The reason I ask was that because all of the locking occurs in a single method call in the Network
Server's JVM, so is there a need to worry about the RMI connection dying during the middle the locking operation.
Edited by: Yucca on May 23, 2009 8:14 PM/*
* @(#)LockManager.java
* Version 1.0.0
* 27/03/2009
import java.util.HashMap;
import java.util.Map;
import java.util.logging.Logger;
import java.util.ResourceBundle;
class LockManager {
     * The <code>Map</code> containing all the record number keys of currently
     * locked records that pair with the cookie value assigned to them when they
     * are initially locked.
    private static Map<Integer, Long> currentlyLockedMap =
            new HashMap<Integer, Long>();
    private static final Logger LOG = Logger.getLogger("project.db");
     * Locks a record so that it can only be updated or deleted by this client.
     * Returned value is a <code>long</code> that is the cookie value that must
     * be used when the record is unlocked, updated, or deleted.
     * If the specified record is already locked by a different client, then the
     * current thread gives up the CPU and consumes no CPU cycles until the
     * record is unlocked.
     * @param   recNo                   the assigned primary key of the record
     *                                  to be locked for an operation.
     * @param   data                    a <code>Data</code> instance used to
     *                                  check if the record exists before
     *                                  attempting the lock operation.
     * @return                          A <code>long</code> containing the
     *                                  cookie value that must be used when the
     *                                  record is unlocked.
     * @throws RecordNotFoundException if specified record does not exist or if
     *                                  specified record is marked as deleted
     *                                  in the database file.
    long lock(int recNo, DB data) throws RecordNotFoundException {
        LOG.entering(this.getClass().getName(), "lock", recNo);
        synchronized (currentlyLockedMap) {
            try {
                while (currentlyLockedMap.containsKey(recNo)
                        && currentlyLockedMap.get(recNo)
                        != Thread.currentThread().getId()) {
                    currentlyLockedMap.wait();
                // Check if record exists.
                data.read(recNo);
                long cookie = Thread.currentThread().getId();
                currentlyLockedMap.put(recNo, cookie);
                LOG.fine("Thread " + Thread.currentThread().getName()
                        + "got Lock for " + recNo);
                LOG.fine("Locked record count = " + currentlyLockedMap.size());
                LOG.exiting(this.getClass().getName(), "lock", true);
                return cookie;
            } catch (InterruptedException ie) {
                throw new SystemException("Unable to lock", ie);
     * Releases the lock on a record. The cookie must be the cookie returned
     * when the record was locked.
     * @param   recNo                   the assigned primary key of the record
     *                                  to be unlocked after an operation.
     * @param   cookie                  the cookie returned when the record was
     *                                  locked.
     * @throws RecordNotFoundException if specified record does not exist or if
     *                                  specified record is marked as deleted
     *                                  in the database file.
     * @throws SecurityException       if the record is locked with a cookie
     *                                  other than cookie.
    void unlock(int recNo, long cookie) throws RecordNotFoundException,
            SecurityException {
        LOG.entering(this.getClass().getName(), "unlock",
                new Object[] { recNo, cookie });
        synchronized (currentlyLockedMap) {
            checkLock(recNo, cookie);
            currentlyLockedMap.remove(recNo);
            LOG.fine("released lock for " + recNo);
            currentlyLockedMap.notifyAll();
        LOG.exiting(this.getClass().getName(), "unlock");
     * Checks if the given record is locked before doing any modification or
     * unlocking for the record.
     * <p/>
     * Checks the <code>Map</code> of record number keys and cookie values
     * to see if it contains the given record number.
     * @param   recNo                   the assigned primary key of the record
     *                                  to be checked if it is locked.
     * @param   lockCookie              the cookie returned when the record was
     *                                  initially locked.
     * @throws SecurityException       if no lock exists for the record or if
     *                                  the record has been locked with a
     *                                  different cookie.
    void checkLock(int recNo, long lockCookie) throws SecurityException {
        LOG.entering(this.getClass().getName(), "checkLock",
                new Object[] { recNo, lockCookie });
        // Check if record has been locked
        if (!currentlyLockedMap.containsKey(recNo)) {
            throw new SecurityException(ResourceBundle.getBundle(
                    "resources.ErrorMessageBundle").getString(
                    "lockNotAppliedKey"));
        // Check if record has been locked by different cookie.
        if (currentlyLockedMap.get(recNo) != lockCookie) {
            throw new SecurityException(ResourceBundle.getBundle(
                    "resources.ErrorMessageBundle").getString(
                    "notLockOwnerKey"));
        LOG.exiting(this.getClass().getName(), "checkLock");
}Edited by: Yucca on May 23, 2009 8:16 PM
Edited by: Yucca on May 23, 2009 8:18 PM

It is my understanding that RMI server can cater for eg 100 clients by spawning 100 threads at random for each client.No. It spawns a new thread for every new connection. At the client end, RMI makes a new connection for every call unless it can find an idle connection to the same host that is less than 15 seconds old. So if the client is doing concurrent calls there will be concurrent threads at the server for that client.
This process is not managed (thread wise)'Managed' meaning what?
the result is that 20 clients wishing to update record A can do so at will?The result is that an RMI server is not thread safe unless you make it so.
a) Synchronise (expensive)Compared to a database update the cost of synchronization is trivial.
b) implement a lock manager. The database should already have one of those, and so does java.util.concurrent. Don't write your own. Personally I would just syncrhonize around the database calls.
what happens if for eg the 1st RMI client dies and has its thread(a) the client doesn't have a thread, see above. The call has a thread.
(b) at the server, the call will execute, regardless of the state of the client, until it is time to write the result back to the client, at which point the write will encounter an IOException of some description and the thread will exit.
blocking all other threads from locking the same record?That can't happen unless you foul up your concurrency management.
Does the thread die with the clientIt dies with the call.
is there a need to worry about the RMI connection dying during the middle the locking operation.The server JVM won't notice until it is time to write the call result back, see above.

Thread Safe Issue with Servlet

I saw the following statement in one of the J2EE compliant server documentations:
"By default, servlets are not thread-safe. The methods in a single servlet instance are usually executed numerous times simultaneously (up to the available memory limit)."
I'm quite concerned with this statement for the primary reason that (I'm trying to reason by reading it out loud) servlets are not going to be thread-safe especially when available memory hit really really low!! So, when the application is still having sufficient memory, we will not likely run into concurrency problems, i.e the happy scenario for a short period after server is started. BUT, good things don't last long.. Anyway, hope someone can explain to me with more insights. Thanks.

Don't worry, memory occupation and thread safety are not related at all.
In my opinion, the following is the meaning of the statement you quote.
Since the servlet specification doesn't force any implementation to spawn a new servlet object upon each request (and this should be a real memory hit!), nor to synchronize calls to servlet methods, you should always code your servlet in a "stateless" fashion: you should be aware the same method on the same object could (and probably will) be called concurrently if multiple concurrent client requests are submitted.
Hope I've been clear enough...

What does it mean to be "thread safe"?

What does it mean to be "thread safe"?
I am working with a team on a project here at work. Someone here suggested that we build all of our screens during the initialization of the application to save time later. During the use of the application, the screens would then be made visible or invisible.
One of the objections to that idea was that the swing components (many of which we use) are not thread safe. Can anyone tell me what the relevance of that is?
Thanks

To understand why Swing is not thread safe you have to understand a little bit of history, and a little bit of how swing actually works. The history(short version) is that it is nearly impossible to make a GUI toolkit thread safe. X is thread safe(well, sorta) and it's a really big mess. So to keep things simple(and fast) Swing was developed with an event model. The swing components themselves are not thread safe, but if you always change them with an event on the event queue, you will never have a problem. Basically, there is a Thread always running with any GUI program. It's called the awt event handler. When ever an event happens, it goes on an event queue and the event handler picks them off one by one and tells the correct components about it. If you have code that you want to manipulate swing components, and you are not ON the awt thread(inside a listener trail) you must use this code.
SwingUtilities.invokeLater( new Runnable() {
public void run() {
// code to manipulate swing component here
});This method puts the defined runnable object on the event queue for the awt thread to deal with. This way changes to the components happen in order, in a thread safe way.

Coherence SimpleParser class is not thread safe?

Coherense has very convinent XML utility class, which we use it a lot within our Coherence related applications.
But we encounter some mysterious lock up (maybe deadlock?) issue and identified that it might be that the com.tangosol.run.xml.SimpleParser class is not thread safe.
We are using tomcat 6 and spring 2.0.6.
One of the webapp has 2 bean which implements InitializingBean interface.
Bean A's afterPropertiesSet() method will use com.tangosol.run.xml.XmlHelper.loadXml method to parse a XML file.
Bean B's afterPropertiesSet() method will acts as a tcp extend client and retrieve some data from a coherence cluster. Which I believe coherence will also use it's XML utility class when parsing the configuration files.
We encounter tomcat lockup (which never finish startup webapp deployment porcess) randomly like 1 out of 2 or 3 tries.
Use jconsole and connect to tomcat we can see that the main thread stuck in SimpleParser class. Here is the thread dump.
Name: main
State: RUNNABLE
Total blocked: 156 Total waited: 0
Stack trace:
com.tangosol.run.xml.SimpleParser.instantiateDocument(SimpleParser.java:150)
com.tangosol.run.xml.SimpleParser.parseXml(SimpleParser.java:115)
- locked com.tangosol.run.xml.SimpleParser@f10c77
com.tangosol.run.xml.SimpleParser.parseXml(SimpleParser.java:71)
com.tangosol.run.xml.SimpleParser.parseXml(SimpleParser.java:84)
com.tangosol.run.xml.XmlHelper.loadXml(XmlHelper.java:109)
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1201)
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1171)
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:425)
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:251)
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:156)
- locked java.util.concurrent.ConcurrentHashMap@dee55c
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:248)
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:160)
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:287)
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:352)
- locked java.lang.Object@d21555
org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:244)
org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:187)
org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:49)
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3830)
org.apache.catalina.core.StandardContext.start(StandardContext.java:4337)
- locked org.apache.catalina.core.StandardContext@1c64ed8
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
- locked java.util.HashMap@76a6d9
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:825)
org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:714)
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:490)
org.apache.catalina.startup.HostConfig.start(HostConfig.java:1138)
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
- locked org.apache.catalina.core.StandardHost@1c42c4b
org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
- locked org.apache.catalina.core.StandardHost@1c42c4b
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
- locked org.apache.catalina.core.StandardEngine@37fd24
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
org.apache.catalina.core.StandardService.start(StandardService.java:516)
- locked org.apache.catalina.core.StandardEngine@37fd24
org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
- locked [Lorg.apache.catalina.Service;@1cc55fb
org.apache.catalina.startup.Catalina.start(Catalina.java:566)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
java.lang.reflect.Method.invoke(Unknown Source)
org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
After we add the depends-on tag to enforce bean B wait on bean A to finish initialization, we no longer encounter the lockup during tomcat startup.
We suspect that maybe SimpleParser class is not thread safe and will cause potential deadlock issue.
Edited by: user639604 on Jun 22, 2009 10:36 AM

While it doesn't show up as deadlock, I believe it probably is, as evidenced by these two threads:
"Timer-0" prio=10 tid=0xcb9a2800 nid=0x454b in Object.wait() [0xcb6e0000..0xcb6e10a0]
   java.lang.Thread.State: RUNNABLE
     at com.tangosol.run.xml.SimpleParser.instantiateDocument(SimpleParser.java:150)
    at com.tangosol.run.xml.SimpleParser.parseXml(SimpleParser.java:115)
     - locked <0xf44e52f0> (a com.tangosol.run.xml.SimpleParser)
     at com.tangosol.run.xml.SimpleParser.parseXml(SimpleParser.java:71)
     at com.tangosol.run.xml.SimpleParser.parseXml(SimpleParser.java:99)
     at com.tangosol.run.xml.XmlHelper.loadXml(XmlHelper.java:129)
     at com.tangosol.run.xml.XmlHelper.loadXml(XmlHelper.java:95)
     at com.tangosol.run.xml.XmlHelper.loadXml(XmlHelper.java:72)
     at com.tangosol.util.ExternalizableHelper.<clinit>(ExternalizableHelper.java:4466)
     at com.evidentsoft.opcache.coherence.OPCacheCoherenceStorage.retrieve(OPCacheCoherenceStorage.java:341)
     at com.evidentsoft.opcache.coherence.OPCacheCoherenceStorage.retrieve(OPCacheCoherenceStorage.java:420)
     at com.evidentsoft.opcache.OPCacheManager.find(OPCacheManager.java:68)
     at com.evidentsoft.logserver.coherence.ClusterDetector.detectNewClusters(ClusterDetector.java:97)
     at com.evidentsoft.logserver.coherence.ClusterDetector.access$000(ClusterDetector.java:19)
     at com.evidentsoft.logserver.coherence.ClusterDetector$1.run(ClusterDetector.java:67)
     at java.util.TimerThread.mainLoop(Unknown Source)
     at java.util.TimerThread.run(Unknown Source)
"main" prio=10 tid=0x08059000 nid=0x4539 in Object.wait() [0xf7fd0000..0xf7fd11f8]
   java.lang.Thread.State: RUNNABLE
     at com.tangosol.run.xml.SimpleParser.instantiateDocument(SimpleParser.java:150)
     at com.tangosol.run.xml.SimpleParser.parseXml(SimpleParser.java:115)
     - locked <0xf44ecd90> (a com.tangosol.run.xml.SimpleParser)
     at com.tangosol.run.xml.SimpleParser.parseXml(SimpleParser.java:71)
     at com.tangosol.run.xml.SimpleParser.parseXml(SimpleParser.java:84)
     at com.tangosol.run.xml.XmlHelper.loadXml(XmlHelper.java:109)
     at com.evidentsoft.coherence.util.ClusterConfigurator.generateConfigFile(ClusterConfigurator.java:319)
     at com.evidentsoft.coherence.util.ClusterConfiguratorProxy.afterPropertiesSet(ClusterConfiguratorProxy.java:51)
     at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1201)
     at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1171)
     at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:425)
     at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:251)
     at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:156)
     - locked <0xd65efb88> (a java.util.concurrent.ConcurrentHashMap)
     at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:248)
     at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:160)
     at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:287)
     at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:352)
     - locked <0xd65efc28> (a java.lang.Object)
     at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:244)
     at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:187)
     at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:49)
     at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3830)
     at org.apache.catalina.core.StandardContext.start(StandardContext.java:4337)
     - locked <0xd6092f60> (a org.apache.catalina.core.StandardContext)
     at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
     - locked <0xd54ff278> (a java.util.HashMap)
     at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
     at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
     at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:825)
     at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:714)
     at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:490)
     at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1138)
     at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
     at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
     at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
     - locked <0xd54ff1e8> (a org.apache.catalina.core.StandardHost)
     at org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
     - locked <0xd54ff1e8> (a org.apache.catalina.core.StandardHost)
     at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
     - locked <0xd4fa60b8> (a org.apache.catalina.core.StandardEngine)
     at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
     at org.apache.catalina.core.StandardService.start(StandardService.java:516)
     - locked <0xd4fa60b8> (a org.apache.catalina.core.StandardEngine)
     at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
     - locked <0xd4f17ea0> (a [Lorg.apache.catalina.Service;)
     at org.apache.catalina.startup.Catalina.start(Catalina.java:566)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
     at java.lang.reflect.Method.invoke(Unknown Source)
     at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
     at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)The reason it isn't showing up as a deadlock in the thread dump is that the ExternalizableHelper static initializer isn't completing, so the other thread (blocking it) is waiting indefinitely on that class to become available.
Peace,
Cameron Purdy | Oracle Coherence

Java.util.Locale not thread-safe !

In multithreading programming, we know that double-checking idiom is broken. But lots of code, even in sun java core libraries, are written using this idiom, like the class "java.util.Locale".
I have submitted this bug report just now,
but I wanted to have your opinion about this.
Don't you think a complete review of the source code of the core libraries is necessary ?
java.util.Locale seems not to be thread safe, as I look at the source code.
The static method getDefault() is not synchronized.
The code is as follows:
public static Locale getDefault() {
// do not synchronize this method - see 4071298
// it's OK if more than one default locale happens to be created
if (defaultLocale == null) {
// ... do something ...
defaultLocale = new Locale(language, country, variant);
return defaultLocale;
This method seems to have been synchronized in the past, but the bug report 4071298 removed the "synchronized" modifier.
The problem is that for multiprocessor machines, each processor having its own cache, the data in these caches are never synchronized with the main memory.
The lack of a memory barrier, that is provided normally by the "synchronized" modifier, can make a thread read an incompletely initialized Locale instance referenced by the static private variable "defaultlocale".
This problem is well explained in http://www.javaworld.com/javaworld/jw-02-2001/jw-0209-double.html and other documents about multithreading.
I think this method must just be synchronized again.

Shankar, I understand that this is something books and articles about multithreading don't talk much about, because for marketing reasons, multithreading is supposed to be very simple.
It absolutely not the case.
Multithreading IS a most difficult topic.
First, you must be aware that each processor has its own high-speed cache memory, much faster than the main memory.
This cache is made of a mixture of registers and L1/L2/L3 caches.
Suppose we have a program with a shared variable "public static int a = 0;".
On a multiprocessor system, suppose that a thread TA running on processor P1 assign a value to this variable "a=33;".
The write is done to the cache of P1, but not in the main memory.
Now, a second thread TB running on processor P2 reads this variable with "System.out.prinln(a);".
The value of "a" is retrieved from main memory, and is 0 !
The value 33 is in the cache of P1, not in main memory where its value is still 0, because the cache of P1 has not been flushed.
When you are using BufferedOutputStream, you use the "flush()" method to flush the buffer, and the "synch()" method to commit data to disk.
With memory, it is the same thing.
The java "synchronized" keyword is not only a streetlight to regulate traffic, it is also a "memory barrier".
The opening brace "{" of a synchronized block writes the data of the processor cache into the main memory.
Then, the cache is emptied, so that stale values of other data don't remain here.
Inside the "synchronized" block, the thread must thus retrieve fresh values from main memory.
At the closing brace "}", data in the processor cache is written to main memory.
The word "synchronized" has the same meaning as the "sync()" method of FileDescriptor class, which writes data physically to disk.
You see, it is really a cache communication problem, and the synchronized blocks allows us to devise a kind of data transfer protocol between main memory and the multiple processor local caches.
The hardware does not do this memory reconciliation for you. You must do it yourself using "synchronized" block.
Besides, inside a synchronized block, the processor ( or compiler ) feels free to write data in any order it feels most appropriate.
It can thus reorder assignments and instruction.
It is like the elevator algorithm used when you store data into a hard disk.
Writes are reordered so that they can be retrieved more efficiently by one sweep or the magnetic head.
This reordering, as well as the arbitrary moment the processor decides to reconciliate parts of its cache to main memory ( if you don't use synchronized ) are the source of the problem.
A thread TB on processor P2 can retrieve a non-null pointer, and retrieve this object from main memory, where it is not yet initialized.
It has been initialized in the cache of P1 by TA, though, but TB doen't see it.
To summarize, use "synchronized" every time you access to shared variables.
There is no other way to be safe.
You get the problem, now ?
( Note that this problem has strictly nothing to do with the atomicity issue, but most people tend to mix the two topics...
Besides, as each access to a shared variable must be done inside a synchronized block, the issue of atomicity is not important at all.
Why would you care about atomicity if you can get a stale value ?
The only case where atomicity is important is when multiple threads access a single shared variable not in synchronized block. In this case, the variable must be declared volatile, which in theory synchronizes main and cache memory, and make even long and double atomic, but as it is broken in lots of implementation, ... )

ODBC SQLGetData not thread-safe when retrieving lob

Hi MaxDB developpers,
we are in the process of migrating our solution from SapDb 7.4.03.32 to MaxDb 7.6.03.7. We use the ODBC driver on windows, from multi-threaded applications.
We encountered bugs in the ODBC driver 7.4.03.32 and made our own fixes since we had the sources. I checked if these problems were fixed in 7.6.03.7 and they are allmost addressed, but one:
when two threads use two different stmt from the same dbc and call simultaneously SQLGetData to retrieve a LONG column, a global variable not protected by a critical section is changed and the application crashes. The variable in cause is dbc_block_ptr->esqblk.sqlca.sqlrap->rasqlldp which is set by pa30bpcruntime and reset by pa30apcruntime during the call to apegetl. Calls to apegetl are protected by PA09ENTERASYNCFUNCTION except in SQLGetData, when it calls pa60MoveLongPos or pa60MoveLong.
Since MaxDB is a critical feature of our application, we would like to know when this bug can be fixed by SAP. Or maybe could we get access to the sources of sqlod32w.dll 7.6.03.7 to fix it ourselves ?
Thanks,
Guillaume

Hello Guillaume
Regarding the threaded access to SQLGetData. Of course, it is possible to manage the syncronization as you proposed. However, I'm still not sure, whether this really solves general problems.
The point is, that the MaxDB-ODBC driver is thread safe for concurrent connections, but not for concurrent statement processing within a single connection. Therefore I would like to ask you how your application accesses data via SQLGetData (due to connections and threads), and what amount of data is usually transfered.
Regards Thomas

Are CacheStore's and BackingMapListener's thread safe?

I'm implementing a JMS CacheStore and have a quick question: does Coherence ever attempt to run multiple threads concurrently across a CacheStore instance on a given node?
Reason I ask is that only certain objects are thread-safe in the JMS spec.: Connection Factories, Destinations (i.e. a Queue) and Connections. However Sessions, Producers and Consumers are not.
In order to improve performance, it's recommended (obviously) to try and reuse Sessions/Producers and not recreate them for every message sent. So I'd like to declare them as instance variables in my class and assign them once-only at construction time.
I just wanted to make sure that this would be OK (i.e. Coherence would start multiple threads running across my CacheStore). Anyone any ideas?
(NB. I'm using JMS Connection Pooling to get around this issue at the moment - as the pools are thread-safe and I can close/open them quickly as many times as I like - but this is not a part of the JMS standard, so I end up using vendor-specific classes which I'd rather not do. Likewise I could make many of these non-thread-safe objects use ThreadLocals, but this all seems a bit overkill if it isn't actually required...)
An other issue... :)
What about closing the connection when it's finished with? Again, it's JMS recommended best-practice to do so. How is this best accomplished, seem as though it was Coherence that created the CacheStore instance and my client code has no reference to it? Best I can think of for now is have a static method in my CacheStore class that is kicked off via an invocation-service agent. Again, if anyone has a better idea I'm all ears.
An other issue... :)
Does the same thread-safety hit BackMapListeners? The "receiving" end of my JMS messages is a BackingMapListener based on the Incubator Commons "AbstractMultiplexingBackingMapListener" class. So, does Coherence ever kick off multiple threads across a single BackingMapListener instance, or can I safely have the JMS Session and Consumer left open after construction as class-level members?
Cheers,
Steve

stevephe wrote:
True... But I was rather hoping I could just get someone from Oracle who wrote the stuff to comment instead! :) Don't really want to second-guess this, as there could always be unusual corner-cases that could be difficult to replicate. Still...
I did a bit more testing on my CacheStore this morning. I removed the non JMS-standard "pooling" and just created instance variables for only those items which I know to be thread-safe (ConnectionFactory, Connection and my target queue, a "Destination" in JMS terminology) I now re-get the Session and Producer in each Cachestore method. This makes the code thread-safe and portable. TBH, it hasn't affected performance too much, so I'll leave it as it is for now (and I've put a comment in the code stating that people could move these things to ThreadLocal's if they wanted to further boost performance in their own usage cases and still keep the CacheStore thread-safe.)
As regards the "receiving" end of these published messages, my BackingMapListener does nothing more than register a JMS MessageListener and a "connection.start()" call. This is a very short, one-off call, so shouldn't leave Coherence service threads "hanging" on anything for extended periods.
Cheers,
SteveHi Steve,
to cut things short:
1. Coherence instantiates one cache store per read-write-backing-map, therefore it needs to be thread-safe if you have a thread-pool or use write-behind.
2. If you don't have write-behind then Coherence uses the worker thread to execute the cache store operations.
3. If you have write-behind then generally Coherence uses the write-behind thread (this is a separate thread per write-behind-configured service) to execute the cache store operations, except for erase[All]() operations on cache.remove() or batch remove which cannot be delayed due to consistency reasons and are executed on the worker thread.
If you don't have a thread-pool, replace worker thread with service thread.
I don't know off my head where the refresh-ahead operation executes.
There is a single backing-map-listener per backing map instantiated, therefore it needs to be thread-safe. BackingMapManagerContext is thread-safe, so there is no issue with sharing it across multiple threads executing on a backing-map-listener.
Best regards,
Robert

Is abap thread safe? Some question in Singleton pattern in ABAP

Hi Grus,
I have a very basic question but really make me headache...
Recently I am learning the design pattern in ABAP and as you know in JAVA there is a key word "Synchronized" to keep thread safe. But in ABAP, I didn't find any key words like that. So does that mean ABAP is always a single thread language? And I found that there is a way looks like "CALL FUNCTION Remotefunction STARTING NEW TASK Taskname DESTINATION dest" to make multi-thread works. As you can see it use the destination, so does that mean actually the function module is always executed in a remote system, and in every system, it is always single thread?
Could you help me on the question? Thanks a lot, grus
And here comes up to my mind another question...It's a little bit mad but I think it may works....What if I set every attribute and method as static in the singleton class...Since as you can see it is already a singleton so every attribute in it should be only one piece. So then I don't even need to implement a get_instance( ) method to return the instance. Just call "class_name=>some_method( )" directly then singleton is achieved...What do you think?
BR,
Steve

Steve,
I've the same question, few days ago I tried to use the singleton in ABAP. In Java programming is possible to use the same reference in two sessions or programs, sharing attributes, methods and all data, but I could not do in ABAP.
In my test I created a program with one global class using the singleton pattern, so I expected that when I run my program and see the reference returned after the get_instance method it should be equal to the same program run in another session, but the ABAP will create a new reference and instantiate again.
So I deduced that the only way to share it between sessions in ABAP is using the ABAP Shared Memory Objects.
I can be wrong, but I think that ABAP use a thread by user session (Each window) and we can't change it.
Best regards.

RDBMS non-thread-safe issue

<snip>
This (as you probably know) is due to the fact that the code provided by
most of the DB vendors is not thread safe.
<snip>
Sean's comment, above, speaks to an issue that is causing some concern
within my (large - 180 projects in development) organisation.
May I please ask the forum if there are others out there who have an
understanding of / concern with this "problem"?
My perception (quite possibly flawed) of the "problem" is that the RDBMS
cannot multi-thread data access objects. So we find ourselves in a situation
where we can achieve scaleability in just about all other
performance-sensitive areas of a system's technical architecture (we're
using DCE -- but have found that Encina is not advisable except where there
is a true requirement for heterogeneous distributed 2 phase commit, which we
don't often see.....) but when we go to hit on the RDBMS, we go back to good
ole single-threading.
In certain circumstances, this shortfall of RDBMS technology -- I won't
mention any names, of course, but the initials are "Oracle" -- seems to be
hindering our achievement of a desired technical architecture.
Is this a "Pro*C / PL/SQL stored procedures" problem or is it something that
is in the RDBMSs' DNA?
How can we get around it?
Any comments?
Regards
Jon

Jon
I agree. But it is the best solution within the constraints of existing
technology. At least we don't use a process per client. 10 replicated
copies of a service could service the needs of 100 clients.
Eric
>
At 13:15 6/09/96 EST, you wrote:
Eric
Thanks for your response. Yep. I realise that the issue I've presented is
clearly not something that Forte causes or is responsible for in any way.
Forte can, as you've pointed out, actually help in this area. But I don't
think that getting Forte to spawn another instance of a data access server
is really the best solution. Ie, that's not what we tend to have in mind
when we think about "scaleability". The best solution is -- perhaps -- to
get the RDBMS people to thread-safe all code and libraries. I have pointedly
asked Oracle for a position on this -- and got the usual blank stare.
I also considered whether people might get upset at me for posting what is
clearly a non-Forte-specifc question in a Forte forum. But then I went ahead
and did it anyway. Justification being (assumption follows) that the kind of
people who hang out on the Forte forum may tend to be more
architecture-oriented than your run of the mill VB / SQL*Net / PL/SQL stored
procedures kinda guy/gal, and may be using or considering Forte (plug for
Forte follows) precisely because it clearly enables a superior architecture.
Should proably post to the comp.database.oracle forum, but I just don't know
them as well.
Regards
Jon
From: Eric Gold
To: McLeod, Jon
Cc: [email protected]
Subject: Re: RDBMS non-thread-safe issue
Date: Friday, 6 September 1996 11:21AM
Jon
In response to this message.....read below...
Sean's comment, above, speaks to an issue that is causing some concern
within my (large - 180 projects in development) organisation.
May I please ask the forum if there are others out there who have an
understanding of / concern with this "problem"?
My perception (quite possibly flawed) of the "problem" is that the RDBMS
cannot multi-thread data access objects. So we find ourselves in a situation
where we can achieve scaleability in just about all other
performance-sensitive areas of a system's technical architecture (we're
using DCE -- but have found that Encina is not advisable except where there
is a true requirement for heterogeneous distributed 2 phase commit, which we
don't often see.....) but when we go to hit on the RDBMS, we go back to good
ole single-threading.
In certain circumstances, this shortfall of RDBMS technology -- I won't
mention any names, of course, but the initials are "Oracle" -- seems to be
hindering our achievement of a desired technical architecture.
Is this a "Pro*C / PL/SQL stored procedures" problem or is it something that
is in the RDBMSs' DNA?
How can we get around it?
Any comments?Jon,
Go ahead ask the Forum any questions you want. This "problem"
is not a problem in Forte. What we allow you to do is "replicate" your
data access services so that each one runs inside its own
process. Each one of these processes (aka partitions) has its
own connection to the database. The routing to the replicated
partitions is transparent to the clients. Clients send a
message like "DatabaseService.GetCustomer()" and then the Forte
router sees which replicated copy of the service is not currently
processing a request and routes it to that free replicate. You
can dynamically increase or decrease the number of replicated
copies of the service easily.
We call this feature "load balancing" in Forte. It is achieved
by checking a box in the data access service object definition.
You can dynamically increase/decrease the number of replicates
and also dynamically move replicates to other nodes in the environment.
This approach assumes that you are using application driven
security and not database security. Each replicated copy
of the service is using the same generic username/password
to connect to the database.
I am forwarding this answer to forte-users because others
might not completely understand this feature.
Eric
Eric Gold
Technical Director
Forte Australia
Voice: 61-2-9926-1403
Fax: 61-2-9926-1401
Eric Gold
Technical Director
Forte Australia
Voice: 61-2-9926-1403
Fax: 61-2-9926-1401

HASHMAP is it thread safe really?

Similar Messages

Maybe you are looking for