perl-workflow-devel

[Perl-workflow-devel] AutoCommit in workflow

[Jim B. <cb...@bu...>]

Hello all,

We generally avoid using AutoCommit preferring to commit manually when 
it makes sense for transactional integrity. That is, you do everything 
you need to do for a single transaction, then commit. If something goes 
wrong, you can rollback the entire transaction cleanly.

Workflow defaults to AutoCommit and I was wondering if there would be 
any interest in allowing this to be a passed in parameter. We could 
still allow AutoCommit to be set, but we could also put in manual 
commits at appropriate points in a transaction. This would result in 
some warnings from DBI whan you manually ran the commits (unless we 
shielded the commits with a test for AutoCommit).

Any thoughts one way or the other?

Thanks,
Jim

-- 
Jim Brandt
Administrative Computing Services
University at Buffalo

Re: [Perl-workflow-devel] AutoCommit in workflow

[Jonas B. N. <jo...@gm...>]

Hi Jim,

I prefer handling transactions manually too, as I see it would should  
of course support AutoCommit and non-automatic commits.

As for the actual implementation, it would be nice to eliminate  
possible warnings.


jonasbn


On 01/04/2008, at 19.41, Jim Brandt wrote:
> Hello all,
>
> We generally avoid using AutoCommit preferring to commit manually when
> it makes sense for transactional integrity. That is, you do everything
> you need to do for a single transaction, then commit. If something  
> goes
> wrong, you can rollback the entire transaction cleanly.
>
> Workflow defaults to AutoCommit and I was wondering if there would be
> any interest in allowing this to be a passed in parameter. We could
> still allow AutoCommit to be set, but we could also put in manual
> commits at appropriate points in a transaction. This would result in
> some warnings from DBI whan you manually ran the commits (unless we
> shielded the commits with a test for AutoCommit).
>
> Any thoughts one way or the other?
>
> Thanks,
> Jim
>
> -- 
> Jim Brandt
> Administrative Computing Services
> University at Buffalo
>
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Perl-workflow-devel mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-workflow-devel

Re: [Perl-workflow-devel] AutoCommit in workflow

[Andrew O'B. <an...@or...>]

> Hello all,

> Workflow defaults to AutoCommit and I was wondering if there would be 
> any interest in allowing this to be a passed in parameter. We could 
> still allow AutoCommit to be set, but we could also put in manual 
> commits at appropriate points in a transaction. This would result in 
> some warnings from DBI whan you manually ran the commits (unless we 
> shielded the commits with a test for AutoCommit).
> 
> Any thoughts one way or the other?

I certainly don't see any issue with allowing the AutoCommit setting to
be overridden as long as the default remains the same so we don't
surprise too many people :)

I know that we assume AutoCommit is on by default, for example.

As long at the extra commits that are added into the Workflow codebase
are optionally executed depending on the AutoCommit setting then the
real question then becomes one of intent:

Are you intending that Workflow still commits regularly internally
(which is what I think you're saying) or are you intending to never call
commit in the Workflow codebase at all and leave that to the external
application?

Cheers,

Andrew

Re: [Perl-workflow-devel] AutoCommit in workflow

[Jonas B. N. <jo...@gm...>]

On 06/04/2008, at 23.50, Andrew O'Brien wrote:
>
>> Hello all,
>
>> Workflow defaults to AutoCommit and I was wondering if there would be
>> any interest in allowing this to be a passed in parameter. We could
>> still allow AutoCommit to be set, but we could also put in manual
>> commits at appropriate points in a transaction. This would result in
>> some warnings from DBI whan you manually ran the commits (unless we
>> shielded the commits with a test for AutoCommit).
>>
>> Any thoughts one way or the other?
>
> I certainly don't see any issue with allowing the AutoCommit setting  
> to
> be overridden as long as the default remains the same so we don't
> surprise too many people :)
>
> I know that we assume AutoCommit is on by default, for example.
>
> As long at the extra commits that are added into the Workflow codebase
> are optionally executed depending on the AutoCommit setting then the
> real question then becomes one of intent:
>
> Are you intending that Workflow still commits regularly internally
> (which is what I think you're saying) or are you intending to never  
> call
> commit in the Workflow codebase at all and leave that to the external
> application?
>

Hmmm this might be the actual challenge, from my standpoint; the  
workflow engine should keep it own state and transactions. But getting  
this to balance with transactions in applications utilizing Workflow,  
might be a question of discipline and can prove - difficult.

> Cheers,
>
> Andrew
>

jonasbn

Re: [Perl-workflow-devel] AutoCommit in workflow

[Jim B. <cb...@bu...>]

Jonas Brømsø Nielsen wrote:
> 
> Hmmm this might be the actual challenge, from my standpoint; the  
> workflow engine should keep it own state and transactions. But getting  
> this to balance with transactions in applications utilizing Workflow,  
> might be a question of discipline and can prove - difficult.
> 

As far as how it 'should' work, I think the workflow app should commit 
when a single unit of work (a transaction, which may be multiple 
executes against the DB) is complete. This can be challenging since you 
need to then define what this means to workflow.

In practice, it might not be too bad. I looked at the code a bit and all 
the inserts and updates are in the Persister/DBI module and most actions 
require just a few inserts updates. It might get tricky with an update 
to the main workflow table, an update to an optional extra_data table, 
and the insert of a few history items.

It gets trickier when you think about a passed in DB handle. Without 
autocommit, the outside app might leave transactions pending. But I 
think this has to be the user's problem. We could insert a warning, or 
perhaps commit before we do anything. It would then be workflow's job to 
make sure there were no exit points where you could return the handle 
with a pending transaction.

I'd be interested in trying out some options. Should I create a separate 
branch?

Jim

-- 
Jim Brandt
Administrative Computing Services
University at Buffalo

Re: [Perl-workflow-devel] AutoCommit in workflow

[Jonas B. N. <jo...@gm...>]

Hi Jim,

A branch would be magnificent.

I am getting better and better at merging, I can almost do it with no  
scew-ups. Anyway I need the practice.

The lastest release 0.32_1 (the developer release) could be the point  
you use and we can perhaps create a 0.32_2 prior to 0.32.

Or if you think your contributions in 0.32_1 require more incubation,  
your could branch from the 0.31 release, the latest official release  
and we could merge this branch into 0.32_1 later on.

I am thinking/dreaming about getting started on some of our other  
outstandings on the road map. But I find it hard to find the time with  
my current workload - I would love to get one of my clients hooked on  
workflow so I could get some paid time on Workflow.

 From the road map file:

--
     * Implement dynamically loading of workflows
     * Implement versioning of workflows

There are several feature requests. These have not been inserted into  
the road map yet.

Documentation is getting out of date, this need to be addressed as well.
--

So there should be enough to go around, plus some minor feature  
requests/bugs that we need to get out of the way.

I would also like to consolidate all this information in the Wiki.

jonasbn

On 07/04/2008, at 21.39, Jim Brandt wrote:
>
> Jonas Brømsø Nielsen wrote:
>> Hmmm this might be the actual challenge, from my standpoint; the   
>> workflow engine should keep it own state and transactions. But  
>> getting  this to balance with transactions in applications  
>> utilizing Workflow,  might be a question of discipline and can  
>> prove - difficult.
>
> As far as how it 'should' work, I think the workflow app should  
> commit when a single unit of work (a transaction, which may be  
> multiple executes against the DB) is complete. This can be  
> challenging since you need to then define what this means to workflow.
>
> In practice, it might not be too bad. I looked at the code a bit and  
> all the inserts and updates are in the Persister/DBI module and most  
> actions require just a few inserts updates. It might get tricky with  
> an update to the main workflow table, an update to an optional  
> extra_data table, and the insert of a few history items.
>
> It gets trickier when you think about a passed in DB handle. Without  
> autocommit, the outside app might leave transactions pending. But I  
> think this has to be the user's problem. We could insert a warning,  
> or perhaps commit before we do anything. It would then be workflow's  
> job to make sure there were no exit points where you could return  
> the handle with a pending transaction.
>
> I'd be interested in trying out some options. Should I create a  
> separate branch?
>
> Jim
>
> -- 
> Jim Brandt
> Administrative Computing Services
> University at Buffalo
>

Re: [Perl-workflow-devel] AutoCommit in workflow

[Jim B. <cb...@bu...>]

Jonas Brømsø Nielsen wrote:
> Hi Jim,
> 
> A branch would be magnificent.
> 
> I am getting better and better at merging, I can almost do it with no 
> scew-ups. Anyway I need the practice.
> 
> The lastest release 0.32_1 (the developer release) could be the point 
> you use and we can perhaps create a 0.32_2 prior to 0.32.

That sounds like a good approach. I'll start from 0.32_1.

FYI, I can see the developer release in your directory:

http://search.cpan.org/src/JONASBN/Workflow-0.32_1/

but search.cpan.org doesn't show it as a download option:

http://search.cpan.org/~jonasbn/Workflow-0.31/

Is that by design? I was thinking it would show up in red or something 
as a developer release?

Jim

-- 
Jim Brandt
Administrative Computing Services
University at Buffalo

Re: [Perl-workflow-devel] AutoCommit in workflow

[Jonas B. N. <jo...@gm...>]

Hi Jim,

There has been some problems with PAUSE, but it should be on  
search.cpan.org by now.

jonasbn

On 08/04/2008, at 16.09, Jim Brandt wrote:
>
>
> Jonas Brømsø Nielsen wrote:
>> Hi Jim,
>> A branch would be magnificent.
>> I am getting better and better at merging, I can almost do it with  
>> no scew-ups. Anyway I need the practice.
>> The lastest release 0.32_1 (the developer release) could be the  
>> point you use and we can perhaps create a 0.32_2 prior to 0.32.
>
> That sounds like a good approach. I'll start from 0.32_1.
>
> FYI, I can see the developer release in your directory:
>
> http://search.cpan.org/src/JONASBN/Workflow-0.32_1/
>
> but search.cpan.org doesn't show it as a download option:
>
> http://search.cpan.org/~jonasbn/Workflow-0.31/
>
> Is that by design? I was thinking it would show up in red or  
> something as a developer release?
>
> Jim
>
> -- 
> Jim Brandt
> Administrative Computing Services
> University at Buffalo
>

Re: [Perl-workflow-devel] AutoCommit in workflow

[Jim B. <cb...@bu...>]

Jonas Brømsø Nielsen wrote:
> Hi Jim,
> 
> There has been some problems with PAUSE, but it should be on 
> search.cpan.org by now.
> 
> jonasbn
> 

Now I see it. Latest Dev. Release. Very cool.

Thanks,
Jim

> On 08/04/2008, at 16.09, Jim Brandt wrote:
>>
>>
>> Jonas Brømsø Nielsen wrote:
>>> Hi Jim,
>>> A branch would be magnificent.
>>> I am getting better and better at merging, I can almost do it with no 
>>> scew-ups. Anyway I need the practice.
>>> The lastest release 0.32_1 (the developer release) could be the point 
>>> you use and we can perhaps create a 0.32_2 prior to 0.32.
>>
>> That sounds like a good approach. I'll start from 0.32_1.
>>
>> FYI, I can see the developer release in your directory:
>>
>> http://search.cpan.org/src/JONASBN/Workflow-0.32_1/
>>
>> but search.cpan.org doesn't show it as a download option:
>>
>> http://search.cpan.org/~jonasbn/Workflow-0.31/
>>
>> Is that by design? I was thinking it would show up in red or something 
>> as a developer release?
>>
>> Jim
>>
>> -- 
>> Jim Brandt
>> Administrative Computing Services
>> University at Buffalo
>>
> 

-- 
Jim Brandt
Administrative Computing Services
University at Buffalo