How to configure webMethods JDBC Adapter to use Oracle RAC

If you have created a JDBC Adapter on WebMethods, it's a really straight forward process, but what happens when we have to connect to a Cluster

Try it and see what happens...

Now it's not that simple isn't?

Thankfully I have a workaround

1. Leave blank serverName, databaseName and portNumber fields.
2. In Other Properties enter your URL:

   url=jdbc:oracle:thin:@(DESCRIPTION=(LOAD_BALANCE=on)
   (ADDRESS=(PROTOCOL=TCP)(HOST=host1) (PORT=1521))
   (ADDRESS=(PROTOCOL=TCP)(HOST=host2) (PORT=1521))
   (CONNECT_DATA=(SERVICE_NAME=service)))

I hope this will help you.

JBPM and Clustering

I'll be precise: "Can JBPM be deployed in a Distributed environment?"
In other words, Can I deploy multiple instances of JBPM? (but I want only 1 JVM to control all the executions)

My answer is Yes, you can have that mode! Just need to disable the JobExecutor on the other instances (by altering the configuration file)

<jbpm-configuration> <import resource="jbpm.businesscalendar.cfg.xml" /> <import resource="jbpm.console.cfg.xml" /> <import resource="jbpm.default.cfg.xml" /> <import resource="jbpm.identity.cfg.xml" /> <import resource="jbpm.task.lifecycle.xml" /> <import resource="jbpm.tx.hibernate.cfg.xml" /> <import resource="jbpm.variable.types.xml" /> <import resource="jbpm.bpmn.cfg.xml" /> <import resource="jbpm.bpmn.flownodes.xml" /> <import resource="jbpm.jpdl.cfg.xml" /> <!-- (start) --> <!-- Comment this entry on Clustered environments, enable this entry in ONE single JVM though and disable it on the others (4 JVMs in total: Enable it in 1 JVM and Disable it in 3) --> <process-engine-context> <job-executor threads="5" idle-max="60000" lock-millis="840000"/> </process-engine-context> <!-- (end) --> </jbpm-configuration>
Otherwise, you'll see this exception on your consoles (If your JVM's fight for the JOB's):

15:51:55,379 [DispatcherThread] ERROR [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.pvm.internal.job.TimerImpl#385014]
 at org.hibernate.persister.entity.AbstractEntityPersister.check(AbstractEntityPersister.java:1769)
 at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2412)
 at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2312)
 at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2612)
 at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:96)
 at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:279)
 at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:263)
 at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:168)
 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.jbpm.pvm.internal.tx.HibernateSessionResource.prepare(HibernateSessionResource.java:56)
 at org.jbpm.pvm.internal.tx.StandardTransaction.commit(StandardTransaction.java:107)
 at org.jbpm.pvm.internal.tx.StandardTransaction.complete(StandardTransaction.java:64)
 at org.jbpm.pvm.internal.tx.StandardTransactionInterceptor.execute(StandardTransactionInterceptor.java:57)
 at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.executeInNewEnvironment(EnvironmentInterceptor.java:53)
 at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.execute(EnvironmentInterceptor.java:40)
 at org.jbpm.pvm.internal.svc.RetryInterceptor.execute(RetryInterceptor.java:56)
 at org.jbpm.pvm.internal.svc.SkipInterceptor.execute(SkipInterceptor.java:43)
 at org.jbpm.pvm.internal.jobexecutor.DispatcherThread.acquireJobs(DispatcherThread.java:126)
 at org.jbpm.pvm.internal.jobexecutor.DispatcherThread.run(DispatcherThread.java:67)

If you're too lazy to have specific configuration per JVM, and you don't care about those exceptions, you're good to go (because that exception does not impact the Execution of your process instance), however, you can hide it by using Log4J (I'll explain that in another post)