Re: transaction abort with multiple threads

On 05/19/2010 11:45 AM, Daniele Varrazzo wrote:
> What is in your "cmd" (regarding to transaction control?) Transaction
> control is per session, so you shouldn't need sending such commands in
> your threads: you can configure the session beforehand and pass it to
> the thread that will use it to create their own cursors and use them
> just to make the grunt work.

It fails with different commands (and sometimes doesn't fail at all). 
Examples:

SELECT min(T_pp) FROM qt_0 WHERE  S_msg=1

INSERT INTO qt_0 
(_pb_data_origin_,_pb_run_idx_,_pb_run_order_,S_msg,T_pp) VALUES 
('src.latency~p.interconnect~0',8,3,2,8.2)

> You can set autocommit mode on the connection [1]: this will affect
> all the cursors created from it. It should affect performance in a
> positive way: you send the transaction control commands just once and
> they will affect the whole session (i.e. all the connection's
> cursors). In the whole session no transaction is created.

None of the threads calls set_isolation_level() (thus, default 
transaction control is in place).

Conc. performance, I was thinking of the problem that the database 
server may sync every INSERT in autocommit mode, instead of syncing all 
of them at once.

> If this doesn't solve your problem, please post an excerpt of the
> commands you send.

See above - pretty plain simple commands. They operate on temporary 
tables (i.e. qt_0) that are created before the threads are started.

  Joachim

-- 
Joachim Worringen
Senior Performance Architect

International Algorithmic Trading GmbH
fon: +49 (0) 40 711 86 75 27
fax: +49 (0) 40 711 86 75 10

Am Knick 8 - D-22113 Oststeinbek

Geschäfsführer: Yorck Schumacher - Mirko Stamm - Timo Wagner
Gesellschaftssitz: Oststeinbek
Registergericht: Lübeck | Registernummer: HRB 7454HL