Re: JDBC behaviour

my point is functionality is first priority and then comes performance,
no meaning of performance without functionality

autocommit off, should do just autocommit off only, nothing else

On Thu, Feb 18, 2016 at 4:41 PM, Sridhar N Bamandlapally <
sridhar(dot)bn1(at)gmail(dot)com> wrote:

> our scenario is to commit successful transaction without worry of failed
> transactions ( these will be logged for verification into error-log-table )
>
> however, the only method for us in java/framework is to put
> postgresql-checkpoint and do "try-catch, savepoint, statement, on-error
> rollback to savepoint"
>
>
>
> On Thu, Feb 18, 2016 at 4:32 PM, Andreas Joseph Krogh <andreas(at)visena(dot)com>
> wrote:
>
>> På torsdag 18. februar 2016 kl. 11:59:50, skrev Andreas Joseph Krogh <
>> andreas(at)visena(dot)com>:
>>
>> På torsdag 18. februar 2016 kl. 11:43:36, skrev Sridhar N Bamandlapally <
>> sridhar(dot)bn1(at)gmail(dot)com>:
>>
>> The code/framework is written to handle batch inserts, which is common
>> for all databases
>>
>> I feel, PostgreSQL JDBC may need to modify setAutoCommit(false) code to
>> "implicit savepoint - on error - rollback to savepoint"
>>
>>
>> You simply cannot have batch-inserts in the same transaction and
>> expecting the batch not to fail if one of the statements in the batch fails.
>>
>>
>> Note that it's perfectly doable to have a connection-pool configured with
>> autocommit=false and do the transaction-management your self. Then you can
>> do whatever you want when one statement fails. You would want to rollback
>> that statement...
>>
>> --
>> *Andreas Joseph Krogh*
>> CTO / Partner - Visena AS
>> Mobile: +47 909 56 963
>> andreas(at)visena(dot)com
>> www.visena.com
>> <https://www.visena.com>
>>
>>
>
>