Strange delays...

[jcosano]

I hava process instance that creates new process intances of another process…
Process A do a select to one table of database and creates a new process instance of process B for each row, moving contenue of table into variables of process B.

Then, is strange that I have 2 operation that sometimes (not always) delays a lot of time, but always are in the same point.
Point1- ProcessInstance pi = runtime.startProcessInstanceByKey("impacts_flow",variables);
Point2- Map<String, Object> variables = runtime.getVariables(key);

In logs only I can see is this (20 sec…):

29-oct-2010 12:03:22 org.activiti.engine.impl.interceptor.LogInterceptor execute
FINA: — starting StartProcessInstanceCmd ——————————————————–
29-oct-2010 12:03:42 org.activiti.engine.impl.runtime.ExecutionEntity initialize

29-oct-2010 12:02:41 org.activiti.engine.impl.interceptor.LogInterceptor execute
FINA: — starting GetVariablesCmd ——————————————————–
29-oct-2010 12:03:01 org.activiti.engine.impl.db.DbSqlSession flush
‍‍‍‍‍‍‍‍‍

Any idea?

Note:
If i do:

for (int i=0; i<200; i++)
{
runtimeService.startProcessInstanceByKey("impacts_flow", variables);
}
‍‍‍‍‍‍

this delays doesn't appear…

[jbarrez]

That is extremely odd …

What kind of variables are we talking here? How many? (not that it can explain the 20s delay)

Any way you can wrap up a simple unit test that demonstrates the problem?

[jcosano]

I'll try to simplify and see that If I can reproduce eliminating redudent actions.
True, it's now all executions appears this 20sec delay. (but not in each iteration, but each iteration does same)

Next tuesday I'll do it.

[jcosano]

Doing unit test I found the famous 20 sec. delays:

10:25:48,442 FIN  | Waiting as long as 20000 milliseconds for connection.  [org.apache.ibatis.datasource.pooled.PooledDataSource]

And I know the reason, my java service need make an insert/update to an auxiliary table (new table added inside activiti schema).


ProcessEngineImpl engine = (ProcessEngineImpl) ProcessEngines.getDefaultProcessEngine();
DbSqlSessionFactory dbSqlSessionFactory = ((ProcessEngineImpl)engine).getProcessEngineConfiguration().getDbSqlSessionFactory();
SqlSession mysql = dbSqlSessionFactory.getSqlSessionFactory().openSession();
Connection conn = mysql.getConnection();
PreparedStatement pstmt=conn.prepareStatement(INSERT_SQL);
…
pstmt.close();
pstmt=null;

Question1: is correct this code?  My target is be able to use sql, is there a best option for do the same?
Question2: How can do this sql with the same transaction of activiti?  if I commit and after activiti fails I will have inconsistent data…

I suppose that my actual problem is derived that I don't have a commit&close.

[jcosano]

Adding:


conn.commit();
conn.close();

Problem solve, and 20 waitting disappears.

But… how can I made sql but playing with the same transaction that activiti? and if an error appears then all my changes rollback too…

[jbarrez]

The 20 second delay is the Ibatis default waiting time, when it can't get a connection from the connection pool.

Strange that a commit fixes it. However, you are right that this is not the right thing to do since it will mess up the transactional state of your process.

You need some way of getting the current connection (instead of creating a new one).
Therefore, you need to retrieve the DbSqlSession in a bit of a hacky way:
DbSqlSession dbSqlSession = commandContext.getDbSqlSession();
DefaultSqlSession sqlSession = (DefaultSqlSession) dbSqlSession.getSqlSession();
Connection conn = sqlSession.getConnection();

But this should be something that is provided out-of-the-box in Activiti.
I created a Jira for this: http://jira.codehaus.org/browse/ACT-305

[jcosano]

Great!!!

And now.. is more faster!!

 
DbSqlSession dbSqlSession = CommandContext.getCurrent().getDbSqlSession();
DefaultSqlSession sqlSession = (DefaultSqlSession) dbSqlSession.getSqlSession();
Connection conn = sqlSession.getConnection();

Note:
for obtain commandContext I use:
CommandContext.getCurrent()

Now time to migrate to RC1 and Oracle…

[jbarrez]

Note:
for obtain commandContext I use:
CommandContext.getCurrent()

Thats indeed the correct way of getting the commandcontext inside of your Java classes.

Now time to migrate to RC1 and Oracle…

Thats should be no problem 🙂