[JBoss jBPM] - org.hibernate.StaleObjectStateException: jbpm and esb
by sshetty
Hi,
We see the following invocation when we use JBPM to orchestrate our ESB services.
| 2009-03-02 16:00:07,508 DEBUG [org.hibernate.jdbc.AbstractBatcher] about to close PreparedStatement (open PreparedStatements: 1, globally: 1)
| 2009-03-02 16:00:07,508 DEBUG [org.hibernate.jdbc.ConnectionManager] skipping aggressive-release due to flush cycle
| 2009-03-02 16:00:07,508 ERROR [org.hibernate.event.def.AbstractFlushingEventListener] Could not synchronize database state with session
| org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [org.jbpm.job.ExecuteActionJob#63081]
| at org.hibernate.persister.entity.AbstractEntityPersister.check(AbstractEntityPersister.java:1765)
| at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2407)
| at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2307)
| at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2607)
| at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:92)
| at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:250)
| at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:234)
| at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:142)
| at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298)
| at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
| at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
| at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338)
| at org.hibernate.transaction.CacheSynchronization.beforeCompletion(CacheSynchronization.java:59)
| at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:114)
| at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:247)
| at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:86)
| at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:177)
| at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1389)
| at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:135)
| at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:87)
| at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:140)
| at org.jbpm.persistence.jta.JtaDbPersistenceService.endJtaTransaction(JtaDbPersistenceService.java:76)
| at org.jbpm.persistence.jta.JtaDbPersistenceService.close(JtaDbPersistenceService.java:37)
| at org.jbpm.svc.Services.close(Services.java:225)
| at org.jbpm.JbpmContext.close(JbpmContext.java:139)
| at org.jbpm.job.executor.JobExecutorThread.acquireJobs(JobExecutorThread.java:144)
| at org.jbpm.job.executor.JobExecutorThread.run(JobExecutorThread.java:58)
| 2009-03-02 16:00:07,509 DEBUG [org.hibernate.jdbc.ConnectionManager] aggressively releasing JDBC connection
| 2009-03-02 16:00:07,509 DEBUG [org.hibernate.jdbc.ConnectionManager] releasing JDBC connection [ (open PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: 0)]
| 2009-03-02 16:00:07,510 WARN [com.arjuna.ats.arjuna.logging.arjLoggerI18N] [com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator_2] TwoPhaseCoordinator.beforeCompletion - failed fo
| r com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple@53a642
|
|
Here is our env:
anonymous wrote :
| Oracle 10g
| jboss-4.2.3.GA
| jboss-messaging-1.4.2.GA
| jbossesb-4.4.GA
|
Our BPM does not use fork or joins.
Any help appreciated.
Thanks
:)
SShetty
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214312#4214312
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214312
17 years, 1 month
[Security & JAAS/JBoss] - Re: Minimal JBoss config to use GSSAPI/Kerberos acceptSecCon
by chriscorbell
I finally got it working. I had gotten a sample working in a small test Java app. using the external config file brought in by "-Djava.security.auth.login.config" per the Sun sample.
I believe I have confirmed that this usage is not the way to go with JBoss - you need to use the same configuration properties of a "com.sun.security.jgss.accept" that might be defined in such a config file, but do it in the standard JBoss login-config.xml.
The three system property args needed are:
-Djava.security.krb5.realm=(your realm), -Djava.security.krb5.kdc=(your kdc IP), and -Djavax.security.auth.useSubjectCredsOnly=false
(I'm passing these to the JVM via run.sh).
It turns out I was missing a few things in my login-config.xml application-policy, that was the main source of may failure - also missing a couple of steps in my code.
Here's what my policy looks like in login-config.xml:
<application-policy name = "com.sun.security.jgss.accept">
| <authentication>
| <login-module code="com.sun.security.auth.module.Krb5LoginModule"
| flag="required">
| <module-option name="debug">true</module-option>
| <module-option name="realm">MY.TEST.REALM.COM</module-option>
| <module-option name="kdc">10.1.6.100</module-option>
| <module-option name="useKeyTab">true</module-option>
| <module-option name="useTicketCache">true</module-option>
| <module-option name="doNotPrompt">true</module-option>
| <module-option name="keyTab">/Library/sso/myservice/krb5.keytab</module-option>
| <module-option name="storeKey">true</module-option>
| <module-option name="principal">myservice/10.1.6.22</module-option>
| </login-module>
| </authentication>
| </application-policy>
The options for "realm", "kdc", "keyTab" and "principal" are the values that vary based on deployment and particular service.
In source, I found I needed to:
1. unmarshall the GSS context token I've received from the client into a byte array
2. get a GSSManager instance
3. create a new LoginContext with:
new LoginContext("com.sun.security.jgss.accept");
4. Call login() on my LoginContext instance
5. Create a GSSCredentials instance with the manager, using
.createCredential(GSSCredential.ACCEPT_ONLY);
6. Create a GSSContext using the manager, passing the credentials just created to .createContext(...)
7. Use the context to call .acceptSecContext:
gssCtx.acceptSecContext(gssContextBytes, 0, gssContextBytes.length);
Hopefully this is useful for someone else who's trying to achieve the same thing.
- Chris
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214309#4214309
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214309
17 years, 1 month