@singleton behaving like @stateless bean

Question

i am working on an application(enterprize application in java) in which i need is single instance to be shared by multiple thread concurrently for which i have used @singleton . when each user login a value is set in telecallers List by invoking setTeleCallersDetails() remote method. but at certain point when number of user logged in exceed 15 then @singleton starts behaving like @stateless bean as setTeleCallersDetails() start adding value in new tellcaller arraylist. can anybody tell to actually how to solve this problem this my code

@Singleton
@Startup
public class UserSessionBean implements UserRemote {
    volatile List<UserDetails> user;
    volatile List<UserDetails> telecallers;
    volatile List notloggedlt;
    /**
     * Default constructor. 
     * @return 
     */
    @PostConstruct
    private void startup() {
        // TODO Auto-generated constructor stub

        if(user == null){
            user = new ArrayList<UserDetails>();
        }
        if(telecallers == null){
            telecallers = new ArrayList<UserDetails>();
        }
        if(notloggedlt == null){
            notloggedlt =  new ArrayList();
        }
    }


    public List<UserDetails> getUserDetails(){
        return user;
    }

    public List<UserDetails> getTeleCallersDetails(){
        return telecallers;
    }

    public List getNotKLoggedInUsersDetails(){
        return notloggedlt;
    }

    @Lock(LockType.WRITE)
    public void setUserDetails(UserDetails objUser){
        if(!user.isEmpty()){
            Collections.sort(user);
            int location = Collections.binarySearch(user, new UserDetails(objUser.getUserId()));
                if (location >= 0) {
                  user.remove(location);
                }
            }
         user.add(objUser);
    }


    @Lock(LockType.WRITE)
    public void removeUserDetails(String userId){

            Collections.sort(user);
            int location = Collections.binarySearch(user, new UserDetails(userId));
                if (location >= 0) {
                  user.remove(location);
                }

    }

    @Lock(LockType.WRITE)
    public void removeTeleCallersDetails(String userId){
        Collections.sort(telecallers);
        int location = Collections.binarySearch(telecallers, new UserDetails(userId));
            if (location >= 0) {
            telecallers.remove(location);
            }

    }

    @Lock(LockType.WRITE)
    public void setNotKLoggedInUsersDetails(List notloggedusers){
        this.notloggedlt = notloggedusers;
    }

    @Lock(LockType.WRITE)
    public void setNotKLoggedInUserDetail(UserDetails objUser){
        notloggedlt.add(objUser);
    }

    @Lock(LockType.WRITE)
    public void setTeleCallersDetails(UserDetails objUser){
        if(!telecallers.isEmpty()){
        Collections.sort(telecallers);
        int location = Collections.binarySearch(telecallers, new UserDetails(objUser.getUserId()));
            if (location >= 0) {
              telecallers.remove(location);
            }
        }
        telecallers.add(objUser);

    }
}

score 0 · Answer 1 · answered May 06 '14 at 08:28

Garbage Collection: If a singleton class gets garbage collected, then again it's reloaded when needed, by creating a new instance. It happens when there are no references to this class & its instance; all the fields gets defaulted/re-initialized & the previous state is lost.

Class Loaders: In case of multiple class loaders, there can exist multiple copies & each one can have their own singleton instance.

Probably in your case, threads aren't holding any reference to the singleton class, because once they finish, reference is destroyed & the singleton might get garbage collected.

As singleton bean have by default WRITE lock on methods for container managed concurrency, you don't need to explicitly specify LockType for methods & volatile for fields, because only one client can access at a time.

You can try adding loggers to the default constructor, startup & destroy methods to get the idea, what is really happening underneath.

@singleton behaving like @stateless bean

1 Answers1

Linked