OSWF: Weekly OSWorkflow complaint list

JIRA is still down. I'll post these once it comes back up... Don't take
these personally, I'm happy to provide patches.

Four Issues:

1.  HibernateWorkflowStore incomplete?
I noticed that the hibernate WorkflowStore implementation doesn't write to
the "link" tables (i.e. OS_CURRENTSTEP_PREV, OS_HISTORYSTEP_PREV). These
tables provide linkage information between workflow steps and essentially
build the workflow "tree" (with initial step being the root).  Was their
omission just an oversight or was it intentional? I don't have a patch at
the moment, but I think the fix would be pretty easy (just adding some
many-to-ones to the mapping files).

2. JDBCWorkflowStore (and HibernateWorkflowStore) cannot be incorporated
into transactions
I'm running some JDBC updates to some of my application tables along with an
osworkflow step transaction and I want to incorporate all database changes
into a single transaction. Now, I've overrided the the convenient
getConnection() method to return a ThreadLocal Connection that my other JDBC
updates were running through.  But, since JDBCWorkflowStore always calls
cleanup( conn, stmt, rset) (which closes the connection) after EVERY method
call, not only does my transaction end, but the connection is closed behind
my back! evil.  I have a patch that will only close the connection if
getConnection() was not overridden.  This way, my ThreadLocal Connection
(which has autoCommit == false) will be used, but not closed or committed by
JDBCWorkflowStore.  The patch also doesn't throw StoreException when the
JNDI datasource is not defined in osworkflow.xml (since getConnection()
provides the Connections, not jndi)

3. Bug in JDBCWorkflowStore
getEntryState() does a conn = ds.getConnection() instead of a conn =
getConnection(). easy fix. I included it in the patch for #2.

4.  AbstractWorkflow uses WorkflowStore inefficiently
I notice this when I switched over to JDBCWorkflowStore. A single call to
doAction() fires THREE calls to findEntry() (one in doAction(), one in
getAvailableActions() and one in completeEntry().  I understand that both
EBJ, HIbernate, etc cache this object for you. But, JDBC does not.  How
about doing findEntry() once and then passing it around in method signatures
(passing null => do lookup).  Or caching it locally?

-nick





-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
Linux in the Boardroom; in the Front Office; & in the Server Room 
http://www.enterpriselinuxforum.com