Prev: newbie to animation; help with basic how-tos
Next: Regarding philosophy of RESTful architectures
From: Proud Japanese on 16 Jun 2010 19:17
Hi,

We are having some disagreement in our team about whether a workflow
is composed of transactions (my view) or whether a transaction is
composed of many workflows (team leader’s view). Can anyone kindly
comment on this issue? References to webresources and/or books will
be welcome.

Apologies in advance if this is OT.

Thanks,
Hayato
From: Roy Hann on 17 Jun 2010 08:01
Proud Japanese wrote:

> Hi,
>
> We are having some disagreement in our team about whether a workflow
> is composed of transactions (my view) or whether a transaction is
> composed of many workflows (team leader�s view). Can anyone kindly
> comment on this issue? References to webresources and/or books will
> be welcome.
>
> Apologies in advance if this is OT.

In the context of an SQL DBMS the trite answer is that a transaction is
anything you say it is. That is because only the programmer decides
where it ends (by doing a COMMIT or ROLLBACK). I shall ignore the very
knotty question of where the transaction begins...

A better answer is that a transaction should be designed so that it
consists of a sufficient number of updates to put the database into a
new consistent state. In my view it should be the minimum sufficient
number of updates, but that may be an aesthetic preference of mine.

Because a workflow will in general cause the database to be put into a
succession of consistent states, it seems to me that your team leader is
incorrect. (I am going only on the basis of your description of his
view though--which makes no sense at all, so it may be that you have
misinterpreted his position.)

--
Roy

From: Roy Hann on 17 Jun 2010 08:11
Roy Hann wrote:

> Proud Japanese wrote:
>
>> Hi,
>>
>> We are having some disagreement in our team about whether a workflow
>> is composed of transactions (my view) or whether a transaction is
>> composed of many workflows (team leader�s view). Can anyone kindly
>> comment on this issue? References to webresources and/or books will
>> be welcome.
>>
>> Apologies in advance if this is OT.
>
> In the context of an SQL DBMS the trite answer is that a transaction is
> anything you say it is. That is because only the programmer decides
> where it ends (by doing a COMMIT or ROLLBACK). I shall ignore the very
> knotty question of where the transaction begins...
>
> A better answer is that a transaction should be designed so that it
> consists of a sufficient number of updates to put the database into a
> new consistent state. In my view it should be the minimum sufficient
> number of updates, but that may be an aesthetic preference of mine.
>
> Because a workflow will in general cause the database to be put into a
> succession of consistent states, it seems to me that your team leader is
> incorrect. (I am going only on the basis of your description of his
> view though--which makes no sense at all, so it may be that you have
> misinterpreted his position.)

Just thinking about this a bit more, it occurs to me that perhaps your
team-leader is thinking about the ease with which workflows can be
abandoned or undone. Perhaps he is hoping that a simple ROLLBACK will
be sufficient.

That is naive in general, because a workflow may involve operations that
cannot simply be rolled back; they require an entire workflow of their
own to reverse them. For instance, it maybe that the workflow causes a
work order to be emailed synchronously which in turn results in a cheque
being put in the mail, or a hole being dug in the road.

--
Roy

 | 
Pages: 1
Prev: newbie to animation; help with basic how-tos
Next: Regarding philosophy of RESTful architectures