On 07/06/2015 07:10 AM, Filipe Pina wrote:
> 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).
Not following, why throw serialization at a FK?
>
> On Sáb, Jul 4, 2015 at 7:23 , Adrian Klaver <adrian.klaver@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 <melvin6925@gmail.com
>> <mailto:melvin6925@gmail.com>> wrote:
>>
>> --
>> Adrian Klaver adrian.klaver@aklaver.com
--
Adrian Klaver
adrian.klaver@aklaver.com