Executing multiple methods on same java instance

[lourduraj.s]

Hi,
I have a scenario where based on some config parameters, I create
an appropriate Business class instance using java reflection and
invoke a specific method. Now to avoid creating instances for each
request using reflection, I place the java object in a Hashmap once I
create it and serve the class from there.

1. Now I am not sure if doing this would cause threading issues or any
other issues, if there are simultaneous requests to the same Business
class instance. What would be the behaviour in that case?

2. If my Business class were an Stateless EJB and I store the EJB Home
object reference in a Hashmap and serve it for all requests, will it
also cause issues?

Any help is greatly appreciated.

Regards,
Raj

 

[Daniel Pitts]

Hi,
I have a scenario where based on some config parameters, I create
an appropriate Business class instance using java reflection and
invoke a specific method. Now to avoid creating instances for each
request using reflection, I place the java object in a Hashmap once I
create it and serve the class from there.

1. Now I am not sure if doing this would cause threading issues or any
other issues, if there are simultaneous requests to the same Business
class instance. What would be the behaviour in that case?

2. If my Business class were an Stateless EJB and I store the EJB Home
object reference in a Hashmap and serve it for all requests, will it
also cause issues?

Any help is greatly appreciated.

Regards,
Raj

Stateless objects don't have threading issues. Stateful objects need
to protect the invariants of their state in some way. I suggest
reading <http://javaconcurrencyinpractice.com/> Java Concurrency in
Practice. Its a great book that explains what you need to know to
write thread-safe code.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

I have a scenario where based on some config parameters, I create
an appropriate Business class instance using java reflection and
invoke a specific method. Now to avoid creating instances for each
request using reflection, I place the java object in a Hashmap once I
create it and serve the class from there.

1. Now I am not sure if doing this would cause threading issues or any
other issues, if there are simultaneous requests to the same Business
class instance. What would be the behaviour in that case?

Reflection does not influence thread safety.

If multiple threads access the code it should be written
to be thread safe.

2. If my Business class were an Stateless EJB and I store the EJB Home
object reference in a Hashmap and serve it for all requests, will it
also cause issues?

The EJB container will make sure that only one thread uses a
bean object at a time, but you will (unless you tell the EJB container
not to) get multiple bean objects.

It is impossible to say from your description whether that
is a problem or not.

Arne

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Stateless objects don't have threading issues. Stateful objects need
to protect the invariants of their state in some way. I suggest
reading <http://javaconcurrencyinpractice.com/> Java Concurrency in
Practice. Its a great book that explains what you need to know to
write thread-safe code.

Be aware that a stateless session bean is not always a stateless
object !

Stateless in this context mean that multiple calls from the same
client may be served by different bean objects.

The bean objects can still have state even though the benefits
is limited due to the above.

Arne

 

[lourduraj.s]

Thanks Arne and Daniel for your inputs.

I hope the following code snippet could explain my scenario better. I
have a Object locator method which based on config properties, does a
EJB look up for home object or a POJO instantiation and provides the
Object back.

While doing so, it also places the object reference in a HashMap for
future use.
Now I am not sure if this would be tread safe with the entire class
being a singleton class.


if (businessServices.get(taskId) != null) {
obj = businessServices.get(taskId);
}else{
/String serviceType =
(String)configInfo.get(CommonConstants.ATTR_SERVICE_TYPE);

//if the business service is of JNDI type , it will proceed in the
else part
if((serviceType != null) &&
(serviceType.equals(CommonConstants.ATTR_JNDI))){
Context initialContext = new InitialContext(env);
obj = initialContext.lookup(jndiName);
Class clazz = Class.forName(homeClass) ;
Object home = (EJBHome) PortableRemoteObject.narrow(obj, clazz);
obj = home;
businessServices.put(taskId, obj);

}else if ((serviceType != null) &&
(serviceType.equals(CommonConstants.ATTR_POJO))){
obj = Class.forName(className);
businessServices.put(taskId, obj);
}
return obj;
}

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

I hope the following code snippet could explain my scenario better. I
have a Object locator method which based on config properties, does a
EJB look up for home object or a POJO instantiation and provides the
Object back.

While doing so, it also places the object reference in a HashMap for
future use.
Now I am not sure if this would be tread safe with the entire class
being a singleton class.

if (businessServices.get(taskId) != null) {
obj = businessServices.get(taskId);
}else{
/String serviceType =
(String)configInfo.get(CommonConstants.ATTR_SERVICE_TYPE);

//if the business service is of JNDI type , it will proceed in the
else part
if((serviceType != null) &&
(serviceType.equals(CommonConstants.ATTR_JNDI))){
Context initialContext = new InitialContext(env);
obj = initialContext.lookup(jndiName);
Class clazz = Class.forName(homeClass) ;
Object home = (EJBHome) PortableRemoteObject.narrow(obj, clazz);
obj = home;
businessServices.put(taskId, obj);

}else if ((serviceType != null) &&
(serviceType.equals(CommonConstants.ATTR_POJO))){
obj = Class.forName(className);
businessServices.put(taskId, obj);
}
return obj;
}

This code is not thread safe.

You should synchronize on businessServices where you
update it.

You do not need to worry about the test if it is already
in the hash table. A race condition could cause two
threads to both initialize, but it does not matter.

Arne