It's not necessary to commit at all costs, it can fail, just not due to
serialization..
And the transaction can be something as simple as updating a field or
inserting a record (with foreign keys which is one the serialization
checks).
On Sáb, Jul 4, 2015 at 7:23 , Adrian Klaver
<adrian.kla...@aklaver.com> wrote:
On 07/04/2015 10:49 AM, Filipe Pina wrote:
Thanks for the suggestion. I read that some people do use that
strategy
for maintenance sometimes but it's no feasible in this scenario.
I would have to disallow new connections AND kill all existing
connections (as there would be an existing connection pool), but this
won't have the same impact as using LOCKs..
Terminating all sessions will break every other transaction (except
for
the one doing it). Locking database will put all the other on hold.
As we're talking about quick/instant operations on hold will have
impact
on performance but won't cause anything to abort..
I really can't find any other solution for what I need (in short:
make
sure no transactions are left out due to serialization failures)
Which would seem to indicate you have painted yourself into a corner.
The idea of locking an entire database to get one transaction to
commit seems a little extreme to me.
What is this transaction trying to do and why is it necessary that it
commit at all costs?
On 03/07/2015, at 19:00, Melvin Davidson <melvin6...@gmail.com
<mailto:melvin6...@gmail.com>> wrote:
--
Adrian Klaver
adrian.kla...@aklaver.com