On 2018-03-12 18:08, homer@... [firebird-support] wrote:

> I didn't see a way to edit the previous post, so sorry for this
> afterthought.
>
> My concert are:
>
> 1. Since the EBs are executed on the Server, will a transaction
> created in Delphi have any benefit for controlling the sequence of
> execution, or the ability to roll back if a failure occurs in block

An execute block is 'simply' an anonymous stored procedure, so it works
the same as executing stored procedures. And just like stored procedures
(or any other statement in Firebird), they need to be executed within a
transaction (your Delphi component likely starts on implicitly if you
haven't started one explicitly), and just like stored procedures (or
other statements) it is possible to run more than one in a single
transaction.

So yes, you can start a transaction and run multiple execute blocks in
them, and roll back will roll back all executed blocks (assuming you
don't use IN AUTONOMOUS TRANSACTION DO within your execute block).

> 2-n.
> 2. Once the EBs are submitted to the server, is there any way to
> control the order in which they execute. In other words, are they
> executed in serial or parallel.

If your EXECUTE BLOCK does not contain any SUSPEND statements, then your
application will be blocked until it is complete; control is only
returned when execution is done. If your EXECUTE BLOCK has SUSPEND
statements, then you should not forget to fetch all rows, otherwise it
will not have any effect (this is the same as when executing executable
vs selectable stored procedures).

So, without SUSPEND execute block is complete after execute is done and
it cannot be executed in parallel. If your execute block has SUSPEND,
you can interleave fetches between the different blocks, although I
suggest you don't do that, because in general that would lead to hard to
follow code (and consume more resources). However, even here, only one
statement is 'active' at a time (so it is concurrent, but not parallel).

> 3. Do I need to do anything to handle deadlocks if they are executed
> in parallel.

Given they are not executed in parallel, and share the same transaction,
it should not be possible for deadlocks to occur.

Mark