[JBoss jBPM] - Re: JBPM Identity
by jpramondon
I may missing one last thing. It may sound dull, but I've been asking myself and couldn't find any cleaner solution than the one I'm finally using.
So here it is :
When I was using the default ExpressionAssignmentHandler, I used to pass it an Expression. (Well nothing stunning until now). This expression was some kind of clue to which actor was finally getting the task.
Now, I'm using my own AssignmentHandler, but it seems like the only possibility to pass it a clue to which user (or group) is actually getting the task is by using variables. So I end up writing something like this :
In the class that creates a new process instance :
| HashMap<String,Object> variables = new HashMap<String,Object>();
| variables.put(contractID, "" + contractID);
| variables.put("group", "control-attendants");
|
In the AssignmentHandler :
| String group = (String)executioncontext.getVariable("group");
| assignable.setPooledActors(group);
|
It's working, but I hate it. It ties the process definition to my code : the group name is completly resolved in the code.
Is there any other way in the process definition to define a variable that I would get as a clue in my AssignmentHandler ?
Or even a cleaner solution that you would think of ?
Thanks for your time and opinion.
Cheers,
Jerome
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4234555#4234555
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4234555
17 years
jBpm 3.2.3 not releasing database connections
by Brian Westrich
Hello jbpm gurus,
We're seeing database connection leakage with jBPM 3.2.3 in our unit tests.
Specifically, this JUnit test fails, showing that connections are not
being released back to the connection pool:
int connectionsBorrowed = datasource.getBorrowedConnectionsCount();
// getBorrowedConnectionsCount() is a method on
Oracle's UCP connection pooling
JbpmConfiguration config =
JbpmConfiguration.parseResource("jbpm.cfg.xml");
JbpmContext context = config.createJbpmContext();
context.getSession();
assertEquals(connectionsBorrowed + 1,
datasource.getBorrowedConnectionsCount()); // passes
context.close();
assertEquals("db connection leakage", connectionsBorrowed, datasource
.getBorrowedConnectionsCount()); // fails
Here's the snippet of our jbpm.cfg.xml file that configures the
persistence service for our test cases:
<service name="persistence">
<factory>
<bean class="org.jbpm.persistence.db.DbPersistenceServiceFactory">
<field name="dataSourceJndiName"><string value="jdbc/bpsmDS"/> </field>
<field name="isCurrentSessionEnabled"><false /></field>
<field name="isTransactionEnabled"><true /></field>
</bean>
</factory>
</service>
The issue might be related to the DbPersistenceService methods
getConnection(boolean) and getSession(). getConnection(boolean)
initially sets mustConnectionBeClosed to true when we get a connection
out of the datasource, but getSession() then sets this flag back to
false.
As a workaround, we wrote the following custom method for closing a
JbpmContext):
public void close(JbpmContext context) {
Connection connection = context.getConnection();
context.close();
try {
connection.close(); // release connection back to pool
} catch (SQLException e) {
throw new IllegalStateException(e);
}
}
In our non-test environment (where we use JTA transactions), we are
not experiencing connection leakage, so my guess is that the container
(WebSphere) has been closing the connection automatically at the end
of the transaction.
Questions:
1. Have we misconfigured jBPM or is there some other reason why we're
leaking database connections in our test environment?
2. Is it ok if we start explicitly calling connection.close() in the
container? For example, will doing so prevent the container from
committing it's transaction (I'm guessing not)? So far our testing
shows no problems whether or not we explicitly call close() in a JTA
environment, but I wanted to make sure about this....
Looking forward to your thoughts on the above questions,
Brian Westrich
bw(a)mcwest.com
17 years