Jon Leighton wrote:
> I'm one of the developers of the Ruby on Rails web framework.
>
> In some situations, the framework generates an empty transaction
block.
> I.e. we sent a BEGIN and then later a COMMIT, with no other queries in
> the middle.
>
> We currently can't avoid doing this, because a user *may* send queries
> inside the transaction.
>
> I am considering the possibility of making the transaction lazy. So we
> would delay sending the BEGIN until we have the first query ready to
go.
> If that query never comes then neither BEGIN nor COMMIT would ever be
sent.
>
> So my question is: is this a worthwhile optimisation to make? In
> particular, I am wondering whether empty transactions increase the
work
> the database has to do when there are several other connections open?
> I.e. does it cause contention?
>
> If anyone has any insight about other database servers that would also
> be welcome.
The one thing that will be the same for all databases is that
saving the two client-server roud trips for BEGIN and COMMIT
is probably worth the effort if it happens often enough.
The question which resources an empty transaction consumes
is probably database specific; for PostgreSQL the expense is
not high, as far as I can tell.
Yours,
Laurenz Albe
