I have an stateful session bean deployed on Jboss 4.3 with the following config on jboss.xml:
<cache-config>
<idle-timeout-seconds>7200</idle-timeout-seconds>
<remove-timeout-seconds>8000</remove-timeout-seconds>
</cache-config>
IE:
The bean should be passivated after 2 hours of IDLE and removed after 2 hours and 15 minutes.
The problem is: when the client VM is abruptly terminated the bean is neither passivated nor removed.
Is there a way to avoid this?
A container may only passivate a stateful session bean instance when
the instance is not in a transaction.
A container must not passivate a stateful session bean with an
extended persistence context unless the following conditions are met:
All the entities in the persistence context are serializable.
The EntityManager is serializable.
Any interceptor classes associated with the stateful session bean must be Serializable.
The references can possibly restrict the bean from getting passivated.
Related
I am testing server failover in a Wildfly 26 cluster (using standalone-ha.xml config)
The application is a stateful JSF / Jakarta EE8 / CDI war deployment
We are using Deltaspike Data and JPA modules in DAO pattern (with #RequestScoped entity managers)
I have two nodes runnings 1 and 2 and perform the following steps:
Login to a user account on Node 1 to create some session data.
Perform a graceful shutdown of Node 1, logs show Node 1 has left the cluster and is reported in logs at Node 2
Refresh browser
Node 2 loads the replication session data then throws the exception pasted below to say that com.arjuna.ats.jta.cdi.DelegatingTransactionManager is not proxyable. The page doesn't render any content and I have to start a new HTTP session to be able to continue on Node 2
[0m [31m11:31:47,479 ERROR [io.undertow.servlet.request] (default
task-2) UT015005: Error invoking method requestInitialized on listener
class org.jboss.weld.module.web.servlet.WeldInitialListener:
org.jboss.weld.exceptions.UnproxyableResolutionException: WELD-001435:
Normal scoped bean class
com.arjuna.ats.jta.cdi.DelegatingTransactionManager is not proxyable
because it has no no-args constructor - Managed Bean [class
com.arjuna.ats.jta.cdi.NarayanaTransactionManager] with qualifiers
[#Any #Default].
Further down it references one of our CDI #ViewScoped beans (ManageCheers):
Caused by: an exception which occurred: in object of type
org.jboss.weld.bean.proxy.util.SerializableClientProxy in field
com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.transactionManager
in object
com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired#2cbfe004
in object of type
com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired
in field
org.jboss.weld.interceptor.proxy.InterceptionContext.interceptorInstances
in object
org.jboss.weld.interceptor.proxy.InterceptionContext#7ce2923f in
object of type org.jboss.weld.interceptor.proxy.InterceptionContext
in field
org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.ctx in
object
org.jboss.weld.interceptor.proxy.InterceptorMethodHandler#651c0cb2 in
object of type
org.jboss.weld.interceptor.proxy.InterceptorMethodHandler in field
org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.interceptorMethodHandler
in object
org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler#36f06fd5
in object of type
org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler
in field
com.myapp.actions.notifications.ManageCheers$Proxy$_$$WeldSubclass.methodHandler
in object
com.myapp.actions.notifications.ManageCheers$Proxy$$$WeldSubclass#4e106109
in object of type
com.myapp.actions.notifications.ManageCheers$Proxy$$$_WeldSubclass
in object of type javax.faces.component.UIViewRoot$ViewMap in object
of type com.sun.faces.util.LRUMap
-----UPDATE
The problem seems to be linked to the
#Transactional(Transactional.TxType.REQUIRED)
annotation, if I remove this annotation from our CDI bean it does not occur, but then we have no transactions.
I notice that NarayanaTransactionManager is #ApplicationScoped so maybe the server shutdown is causing it to be re-created?
Looks like com.arjuna.ats.jta.cdi.NarayanaTransactionManager is being put into your session state but is not compatible with the state replication.
Are you actually expecting this to be part of your state? Feels like it's not intentional
You could maybe enable sticky session to avoid session replication (from one node to another) ?
https://docs.wildfly.org/26/wildscribe/subsystem/undertow/configuration/filter/mod-cluster/balancer/index.html
This seems to be a bug in Narayana, I forked the library and added a no-args constructor to the DelegatingTransactionManager and the exception no longer occurs.
Bug reported here:
https://issues.redhat.com/projects/JBTM/issues/JBTM-3703?filter=allopenissues
I'm migrating my application from JBoss 7 to WildFly (v9.0.1) and it is not deployed because of bean transaction management error.
Caused by: javax.naming.NamingException: WFLYNAM0062: Failed to lookup env/com.component.eventmgt.EventServiceImpl/transaction [Root exception is java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: java:jboss/UserTransaction]
at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:157)
at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:316)
... 90 more
Caused by: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: java:jboss/UserTransaction
at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:319)
at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:143)
... 95 more
Caused by: javax.naming.NameNotFoundException: UserTransaction [Root exception is java.lang.IllegalStateException: WFLYEJB0137: Only session and message-driven beans with bean-managed transaction demarcation are allowed to access UserTransaction]
at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:153)
at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:316)
... 96 more
Here is the EventServiceImpl class.
#Stateless
#Remote(EventService.class)
#TransactionAttribute(TransactionAttributeType.REQUIRED)
public class EventServiceImpl implements EventService {
/**
* Logger
*/
private static Logger log = LoggerFactory.getLogger(EventService.class);
private EventTableDAO eventDao;
#PersistenceContext(unitName = "SOMF-GT")
private EntityManager entityManager;
#Resource
private UserTransaction transaction;
public List<Map> loadEvents() throws EventsException {
Configuration configurationEntry = new Configuration();
try {
Map configuration = configurationService.getConfiguration();
if (configuration != null) {
eventDao = new EventTableDAO(Event.class, entityManager, transaction);
List<Map> eventsMapList = new ArrayList();
}
}
I know that if i changed the transaction management to BMT with #TransactionManagement(TransactionManagementType.BEAN) but then the following error emerge
WFLYJPA0060: Transaction is required to perform this operation (either use a transaction or extended persistence context)
I want to know why we have to change this in the first place ?
Any information, please !
These changes rolled out in Wildfly 8 and were (as noted below) based on standardization of the global JNDI namespace in EJB 3.1.
From the Wildfly 8 Developer Guide:
EJB 3.1 introduced a standardized global JNDI namespace and a series of related namespaces that map to the various scopes of a Java EE application. The three JNDI namespaces used for portable JNDI lookups are java:global, java:module, and java:app. If you use JNDI lookups in your application, you will need to change them to follow the new standardized JNDI namespace convention.
To conform to the new portable JNDI namespace rules, you will need to review the JNDI namespace rules and modify the application code to follow these rules.
The guide further notes:
WildFly 8 has tightened up on JNDI namespace names to provide predictable and consistent rules for every name bound in the application server and to prevent future compatibility issues. This means you might run into issues with the current namespaces in your application if they don't follow the new rules.
Here's a snippet from the table showing Examples of JNDI mappings in previous releases and how they might look now specific to the UserTransaction:
Previous Namespace New Namespaces
------------------ --------------
java:comp/UserTransaction java:comp/UserTransaction (This will not be accessible for non EE threads, e.g. Threads your application directly creates)
java:comp/UserTransaction java:jboss/UserTransaction (Globally accessible, use this if java:comp/UserTransaction is not available)
Edit re: WFLYEJB0137:
This is theory-craft and may be worthless - let me know and I'll delete it. Java EE 6 Tutorial - Container-Managed Transactions says:
Enterprise beans that use container-managed transaction demarcation also must not use the javax.transaction.UserTransaction interface.
Further:
(Transaction) Required Attribute
If the client is running within a transaction and invokes the enterprise bean’s method, the method executes within the client’s transaction. If the client is not associated with a transaction, the container starts a new transaction before running the method.
The Required attribute is the implicit transaction attribute for all enterprise bean methods running with container-managed transaction demarcation. You typically do not set the Required attribute unless you need to override another transaction attribute. Because transaction attributes are declarative, you can easily change them later.
The exception message pretty much says it all:
WFLYEJB0137: Only session and message-driven beans with bean-managed transaction demarcation are allowed to access UserTransaction
Your EJB is using container managed transaction (CMT) demarcation which does not inter-operate with bean managed transaction (BMT) demarcation wherein UserTransaction lies.
Regarding a switch to BMT and
WFLYJPA0060: Transaction is required to perform this operation (either use a transaction or extended persistence context)
I found Transaction is required to perform this operation (either use a transaction or extended persistence context) which seems to indicate that the transaction is to be managed by you, as you noted in your comments #Marco. It appears that you have made the appropriate modification.
I am using the java Batch (JSR-352), it is possible to work with a session bean inside it? I needed to have a Bean with #SessionScope annotation, to catch some information in it, that to differentiate the type of User that is running the batch process.
It's possivel use a Session Context CDI inside the specification ? If is possible how is the best pratice
In general, the session isn't going to propagate from the thread starting the job via JobOperator to the execution thread. I don't recall if this is under discussion in the CDI specification still or a settled matter, but for now you can't.
I have read that when ejbPassivate() is called Stateful Session Beans are usually evicted but Entity Beans and Stateless Beans are pooled which means they are not appilicable for passivation.
In another article I have read that activation and passivation is applicable only for Stateful Session Beans and Entity Beans which is a contrast to the claim that Entity Beans and Stateless Beans are pooled.
For what beans does the passivation apply and what does really happen when they do?
Passivation and Activation only apply to EJBs that have state, namely stateful session beans and entity beans.
Passivation is the process by which any state a given bean has is moved into storage.
Activation is the process by which any state that a given bean previously had is loaded from storage.
This mechanism is needed because the EJB contain creates a pool of each bean type but gives the illusion that there are an infinate number of each bean, loading and storing them using the ejbActive and ejbPassivate methods respectively as needed.
The full life-cycle of each bean type is described here:
Stateless Session Bean
Stateful Session Bean
Entity Bean
For (Glassfish v2.1), two RuntimeExceptions from two separate requests from a session bean:
"org.hibernate.SessionException: Session is closed!"
org.hibernate.SessionException: Session is closed!
at org.hibernate.impl.AbstractSessionImpl.errorIfClosed(AbstractSessionImpl.java:72)
at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1138)
at org.hibernate.impl.QueryImpl.list(QueryImpl.java:102)
at org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:67)
[wrapped] javax.persistence.PersistenceException: org.hibernate.SessionException: Session is closed!
at org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:614)
at org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:76)
"java.lang.IllegalStateException: EntityManager is closed"
java.lang.IllegalStateException: EntityManager is closed
at org.hibernate.ejb.EntityManagerImpl.close(EntityManagerImpl.java:97)
at com.sun.enterprise.util.QueryWrapper.clearDelegates(QueryWrapper.java:460)
at com.sun.enterprise.util.QueryWrapper.getResultList(QueryWrapper.java:198)
Both of these EntityManagers were obtained via JNDI lookup (java:comp:/env/TargetSitePersistenceContext)
Using JTA (transaction-type attribute is not defined in persistence.xml).
& SQL Server 2008 w/ sqljdbc4.jar
The code just does the ff:
query = entityManager.createQuery();
query.getResultList();
And that's it. If I'm not mistaken, I believe the app container will handle open/commit/rollback/close, so we shouldn't have any entityManager.close().
What might have caused those two runtime exceptions?
When does GF actually open/close an EntityManager?
Is there any difference between:
an EntityManager obtained via JNDI lookup
via #PersistenceContext Injection? (So far not issues with this style)
All things being equal, a #PersistenceContext injection and a JNDI lookup should return the same EntityManager. So it might be a bug of GlassFish and you might want to reach for them. But make sure to give all the context like type of session bean used for injection, transaction or not etc etc.
Mark your bean with annotation #TransactionAttribute
#Stateless
#TransactionAttribute(TransactionAttributeType.MANDATORY)
public class Repo implements IRepo
{
container managed transaction is regulated by this parameter