Re: Re: OSWF: Weekly OSWorkflow complai nt list

What site?

RAOUL Yann wrote:

> Hi,
> 
> The site is currently down...a file may have been move or deleted.
> 
>  > -----Message d'origine-----
>  > De : Nick Dellamaggiore [mailto:[email protected]]
>  > Envoyé : mardi 21 octobre 2003 23:13
>  > À : [email protected]
>  > Objet : [Opensymphony-developers] Re: OSWF: Weekly OSWorkflow
>  > complaint
>  > list
>  >
>  >
>  > >Definitely, I've commented on the jira issue saying it'd be awfully
>  > > nice if Nick could edit the wiki and add in a note about tx
>  > with jdbc.
>  >
>  > For sure. Give me a few days to take care of it. I have to
>  > put out some
>  > fires here at work...
>  >
>  > -nick
>  >
>  > "Hani Suleiman" <[email protected]> wrote in message
>  > news:[email protected]...
>  > > Definitely, I've commented on the jira issue saying it'd be awfully
>  > > nice if Nick could edit the wiki and add in a note about tx
>  > with jdbc.
>  > >
>  > > On Tuesday, October 21, 2003, at 03:32 AM, Eric Pugh wrote:
>  > >
>  > > > Should we add a section to the wiki detailing the issues
>  > with JDBC?
>  > > > So that
>  > > > other people don't go down the road of trying to use it
>  > and run into
>  > > > the TX
>  > > > problems?  I used the JDBC version b/c it was quick and
>  > easy to test
>  > > > connectivity and persistence with the database, but we should
>  > > > highlight it's
>  > > > limitations.
>  > > >
>  > > > Eric
>  > > >
>  > > >> -----Original Message-----
>  > > >> From: [email protected]
>  > > >> [mailto:[email protected]]On
>  > > >>  Behalf Of
>  > > >> Hani Suleiman
>  > > >> Sent: Tuesday, October 21, 2003 3:38 AM
>  > > >> To: [email protected]
>  > > >> Subject: Re: [Opensymphony-developers] OSWF: Weekly
>  > > >> OSWorkflow complaint
>  > > >> list
>  > > >>
>  > > >>
>  > > >>
>  > > >> On Monday, October 20, 2003, at 02:43 PM, Nick
>  > Dellamaggiore wrote:
>  > > >>
>  > > >>> 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).
>  > > >>>
>  > > >> Yep, makes sense. Submit a patch!
>  > > >>
>  > > >>> 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)
>  > > >>>
>  > > >> This is more problematic. The correct solution really is
>  > to have a
>  > > >> Workflow class (similar to OfbizWorkflow) which can
>  > > >> appropriately start
>  > > >> off a tx and commit it in the Workflow methods. Then
>  > again, we end up
>  > > >> with new stores having to implement two classes
>  > > >> realistically, a store
>  > > >> and a workflow for tx'ness.
>  > > >>
>  > > >> Due to this problem, making JDBC tx-safe is not trivial
>  > nor easy, I
>  > > >> think. I personally would discourage people from using
>  > it for this
>  > > >> reason. I don't see a strong argument for it, since I think that
>  > > >> between them, ofbiz, ejb, and hibernate cover all
>  > possible deployment
>  > > >> situations...or am I wrong?
>  > > >>
>  > > >>> 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.
>  > > >>>
>  > > >> Fixed, thanks.
>  > > >>
>  > > >>> 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?
>  > > >>>
>  > > >> Yeah, again this is another strike against JDBC workflow
>  > store. I'll
>  > > >> have a look at modifying some of the methods to pass
>  > around stuff to
>  > > >> reduce the number of lookups (and accept patches for that).
>  > > >> Note though
>  > > >> that there is an important restriction on the acceptance of
>  > > >> any patches
>  > > >> that do this, that nothing that alters the client facing
>  > API will be
>  > > >> added. So if you change protected/private methods only,
>  > all is well.
>  > > >>
>  > > >>
>  > > >>
>  > > >> -------------------------------------------------------
>  > > >> 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
>  > > >> _______________________________________________
>  > > >> 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
>  > > _______________________________________________
>  > > 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
> 
> 
> 
> 
> 
> -------------------------------------------------------
> 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
> _______________________________________________
> Opensymphony-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/opensymphony-developers
> 




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/