[MySQL] - Trigger e Transazioni Implicite

[milazzo.g]

Salve a tutti,
ho un dubbio, quasi esistenziale: un trigger qualsiasi è visto da mysql come una transazione? Mi spiego meglio, ho un trigger che inserisce un record in una tabella con l'id in auto incremento. Dopo, all'interno dello stesso trigger, devo inserire lo stesso id in un'altra tabella. Per ottenere questo id uso la seguente query (dentro il trigger):

    create trigger mioTrigger   
    after insert on tabellaTarget
    ...
    declare id_cheMiInteressa integer;

    insert into tabella1(attr1, attr2) values ('valore1', 'valore2');

    select id
    into id_cheMiInteressa 
    from tabella1
    order by id desc
    limit 1;
    ...
    insert into altraTabella(id, data) values (id_cheMiInteressa, now());
    ...

Il problema è che se due utenti inseriscono dati contemporaneamente in

tabellaTarget

vengono creati due record in

tabella1

... Quale dei due id appartiene ad un utente? Pensavo di risolvere bloccando le tabelle...
non sapendo se venga lanciato implicitamente il lock sulle tabelle ho provato ad aggiungere al codice

lock tables tabella1 write;

ma mysql mi restituisce un errore dicendomi che non è possibile usare lock all'interno di procedure salvate.
In definitiva quindi, all'interno del trigger e durante l'esecuzione dello stesso, le tabelle interessate sono messe in lock?
Grazie in anticipo!

[razzoli]

Se stai usando MyISAM, non esistono le transazioni.

Se stai usando InnoDB (che è il default a partire da MySQL 5.5) il trigger avviene dentro la stessa transazione dell'istruzione che lo attiva. Cioè la transazione comincia prima della INSERT e finisce dopo il trigger. Il transaction level deve essere SERIALIZABLE.

Questo è sufficiente a garantire l'isolamento. Non usare LOCK TABLES, che distrugge tutti i benefici delle transazioni - e infatti per default InnoDB lo ignora.

[milazzo.g]

Se stai usando MyISAM, non esistono le transazioni.

Se stai usando InnoDB (che è il default a partire da MySQL 5.5) il trigger avviene dentro la stessa transazione dell'istruzione che lo attiva. Cioè la transazione comincia prima della INSERT e finisce dopo il trigger. Il transaction level deve essere SERIALIZABLE.

Questo è sufficiente a garantire l'isolamento. Non usare LOCK TABLES, che distrugge tutti i benefici delle transazioni - e infatti per default InnoDB lo ignora.

Grazie per la risposta, ma ho risolto in un altro modo. Spiego come in modo che possa essere d'aiuto a tutti: praticamente esiste una funzione LAST_INSERT_ID() che restituisce l'ID dell'ultimo elemento inserito con auto_increment. State tranquilli: Restituisce ad ogni client e ad ogni utente il corretto ID, testato sullo stesso pc con lo stesso user ed anche su pc diversi con lo stesso user e non da assolutamente problemi. L'utilizzo è semplicissimo, ad esempio

delimiter //
create procedure mia_procedura()
begin
    declare ultimo_id integer;

    insert into tabella_con_autoincrement(attr2) values ('valore');

    select LAST_INSERT_ID()
    into ultimo_id;

    /* potete farci quel che volete */
end;
//
delimiter ;

[razzoli]

Se non ti interessa metterlo in un trigger, probabilmente non hai bisogno nemmeno di una procedura.

START TRANSACTION;
insert into tabella_con_autoincrement(attr2) values ('valore');
insert into altraTabella(id, data) values (LAST_INSERT_ID(), now());
COMMIT;