lock conflict sur une req select

[veronique]

Bonjour à tous,
j'utilise firebird et java.
dans mon source, je fais un 'select . from . where' tout simple , et la requete déclenche une erreur 'lock conflict on no wait transaction
deadlock'.
Il y a surement une des lignes de cette table qui est locke par un autre utilisateur. Mais je ne fais qu'un select et ma connection est en read only, je ne devrais pas avoir de lock conflict.
Auriez vous une idée pour moi ?
merci d'avance

[Barbibulle]

C'est systématique ?
Ca le fait sous ISQL aussi ? (en prenant la même requete)

[veronique]

Je n'ai pas essayé sous ISQL, mais je vais le faire et je vous dis

En fait je travaille aussi avec du jsp et un serveur tomcat, le problème c'est que cette erreur se produit lorsque mon client travaille avec mon programme jsp et je n'ai pas encore réussi ( ou pris le temps) de reproduire vraiment cette erreur vu que j'ai plus ou moins inhibé cette erreur pour qu'il puisse tourner.

Merci.

[Barbibulle]

Et aussi, quel est le type de la transaction dans lequel votre select s'effectue ?

[veronique]

Voila comment j'initialise mes connections en source java pour le select.

Code java :

1
2
3
4
5
6
7
    int [] tp = {org.firebirdsql.gds.ISCConstants.isc_tpb_version3
     , org.firebirdsql.gds.ISCConstants.isc_tpb_read_committed
     , org.firebirdsql.gds.ISCConstants.isc_tpb_nowait
     , org.firebirdsql.gds.ISCConstants.isc_tpb_read };
 
      ((org.firebirdsql.jdbc.FirebirdConnection)conn).setTransactionParameters(org.firebirdsql.jdbc.FirebirdConnection.TRANSACTION_READ_COMMITTED, tp);
      conn.setAutoCommit(false);

Si quelqu'un connait des sites ou de la doc sur firebird ( plus en français), ou jdbc qui puisse m'aider.
J'ai un peu navigué mais n'est pas trouvé grand chose d'interressant..

Je vais essayer sous ISQL, mais le problème c'est que je ne sais pas exactement quelle requete a mis en with lock un des enregistrements.
Merci.

[Barbibulle]

L'isolation de votre transaction est Read_commited, mais dans ce mode il faut préciser un autre paramétre.
Car par defaut il est à no_rec_version, or dans ce mode, si une autre transaction modifie un enregistrement (mais ne le commit pas encore) la lecture de celui-ci vous retournera une erreur de lock conflict.
Il faut que vous précisez rec_version qui permet dans le même cas de lire la dernière version commitée de l'enregistrement.

Mais bon c'est un choix :
Soit vous utilisez le no_rec_version et si vous avez un erreur vous savez qu'une personne est en train de modifier l'enregistrement mais ne l'a pas encore commité. Donc vous réésseyez plus tard et vous êtes certainne d'avoir les données les plus à jours possible.

Soit vous utilisez le rec_version et dans ce cas vous n'avez pas de probleme de lecture mais par contre ce que vous lisez est peut etre en cours de modification (non validée) et vous ne le savez pas.

Donc pour évitez résoudre votre PB faites :

Code :

1
2
3
4
5
6
7
8
    int [] tp = {org.firebirdsql.gds.ISCConstants.isc_tpb_version3
     , org.firebirdsql.gds.ISCConstants.isc_tpb_read_committed
     , org.firebirdsql.gds.ISCConstants.isc_tpb_rec_version
     , org.firebirdsql.gds.ISCConstants.isc_tpb_nowait
     , org.firebirdsql.gds.ISCConstants.isc_tpb_read };
 
      ((org.firebirdsql.jdbc.FirebirdConnection)conn).setTransactionParameters(org.firebirdsql.jdbc.FirebirdConnection.TRANSACTION_READ_COMMITTED, tp);
      conn.setAutoCommit(false);

[veronique]

Merci beaucoup pour ta réponse
je vais le faire