Concurrent Access to Cache Mechanism

Question

Below I have code from an object that is used for caching data from a database. My question deals with the method getCacheObj(). Does getCacheObj() return a copy of the reference to cacheObj or does it return the actual cacheObj variable itself?
Specifically I am concerned about a concurrency issue when the methods refreshCache() and getCacheObj() are called simultaneously. What would happen in the following situation:
Thread 1 calls findActiveByWebsiteArea() which calls getCacheObj(). getCacheObj() returns the cacheObj for processing down the line in a jsp or other java object. Prior to thread 1 finishing the processing with cacheObj, thread 2 calls refreshCache() which resets cacheObj. Is it possible for thread 2 to clash with thread 1?
public class NewsPeer extends AncestorCachePeer {
    // object that will house the cached data
    protected static NewsPeer cacheObj = null;
    // attributes for the instantiated cache object
    private Hashtable newsByWebsiteArea = null;
    private NewsPeer() {
        // private constructor to enforce a singleton
    public static void refreshCache() throws Exception {
        // reset the cache object so a fresh retrieve will be performed
        // the next time the cache is accessed
        synchronized (cacheObj) {
            cacheObj = null;
    private static NewsPeer getCacheObj() throws Exception {
        synchronized (cacheObj) {
            if (cacheObj == null) {
                cacheObj = new NewsPeer();
                cacheObj.retrieveCache();
            return cacheObj;
    public static List findActiveByWebsiteArea(String websiteareaId) throws Exception{
        // get item from cache obj
        return (List) getCacheObj().newsByWebsiteArea.get(websiteareaId);
    private void retrieveCache() throws Exception {
        // code to populate newsByWebsiteArea on cacheObj
}

Answer 1

I feel it's not a good idea to make your lock object null somewhere ...
for example, let us say refreshCache() method acquired the lock.
but before it performs CacheObj = null, it gets descheduled, and another thread, runs getCacheObj() and since it
cannot get the cacheObj, it waits on cacheObj's queue, and now the previous thread resumes, which makes cacheObj null.
It will be better if you can have a separate lockObject.
This is my suggestions and I may be wrong. So let us wait for the experts to give some more suggestions..