RE: OSWF: Weekly OSWorkflow complaint list

I would be happy to look at some of these for you, specifically the
hibernate one..  Could you whip up a unit test for these?  I think that for
the hibernate issue, you could extend the existing functional unit test to
check the OS_CURRENTSTEP_PREV/OS_HISTORYSTEP_PREV records where created and
then all the SPI's would be able to take advantage of those checks...

And then the JDBC one maybe demonstrate the close being called.  It would
also provide a nice example of what you are doing with the transactions for
new people to look at.

Eric

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On
>  Behalf Of
> Nick Dellamaggiore
> Sent: Monday, October 20, 2003 8:44 PM
> To: [email protected]
> Subject: [Opensymphony-developers] 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
> _______________________________________________
> Opensymphony-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/opensymphony-developers



-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54