PostgreSQL
La base de données la plus sophistiquée au monde.

Ouverture de session

Navigation

Contactez-nous

Administration du site :
"equipe chez postgresqlfr point org"

Contact presse :
"fr chez postgresql point org"

Contact association :
"bureau chez postgresqlfr point org"

Questions PostgreSQL :
 IRC :
  serveur irc.freenode.net
  canal #postgresqlfr

Recherche

Accéder aux archives

« Octobre 2008  
Lun Mar Mer Jeu Ven Sam Dim
  2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31  

Syndication

Flux XML

Sondage

Quelle est la version de PostgreSQL la plus répandue sur vos serveurs ?
8.3
10%
8.2
42%
8.1
40%
8.0
2%
7.4
6%
7.3 ou antérieure
0%
Nombre de votes: 48

Blocage de transactions

Technique - général | Blocage de transactions

Par grouvi le 03/07/2008 - 11:47

Bonjour,

Chez mes clients je rencontre un problème de blocage de transaction.

Je le constate de la manière suivante avec pgAdmin :
- Dans l'onglet verrous, j'ai plusieurs lignes qui ne disparait jamais.
- Dans l'onglet transactions, j'ai une ligne qui ne disparait jamais également.

Nous utilisons un version 8.1.4 sur machine windows.
Les connections à la base de donnée postgres se font via jdbc (driver de la 8.1.4).
Nous utilisons un serveur jboss 4.2.0 avec hibernate 3.2.
Nos data sources sont définies en XA, nous sommes donc en 2 phase commit.

Si je relance postgres ou leserveur jboss les verrous persistent.

D'après ce que j'ai constaté, il semble que la dernière requete exeécutée est un PREPARE TRANSCATION.

J'aimerais pouvoir déterminer si c'est postgres qui bloque sur le PREPARE ou bien s'il ne reçoit jamais de commit/rollback.
Comment puis-je procéder ?
Autrement avez vous une piste pour m'aider à résoudre mon problème ?

Je vous remercie.

Options d'affichage des commentaires

Sélectionnez la méthode d'affichage des commentaires que vous préférez, puis cliquez sur "Sauvegarder les paramètres" pour activer vos changements.

XA ?!

Jean-Paul Argudo/ = 7 Juillet, 2008 - 07:50

Bonjour,

Avez-vous essayé en dévalidant le XA? Pourquoi utiliser le two phase commit?

À mon humble avis, ça vient de là...

Pouvez-vous essayer sans le XA et venir nous dire ce qu'il en est?

Merci!

--
Jean-Paul ARGUDO
http://dalibo.com | http://dalibo.org


Bonjour, Nous utilisons le

grouvi/ = 7 Juillet, 2008 - 17:03

Bonjour,

Nous utilisons le XA car nous utilisons plusieurs datasources dans une transaction :
- la datasource de notre application
- la datasource du JMS

Au départ nous étions en one phase commit, mais jboss se plaignait qu'il ne pouvait garantir l'état transactionnel à partir du moment ou il y avait plusieurs one phase datasources utilisées dans la même transaction.

Il faut noter que nous utilisons également une no-tx-datasource dans le but de pouvoir à tout moment comparer des valeurs de tables à l'état dans lequel il se trouve en base et non celui de la transaction courante.

Pourquoi le XA conduirait-il à des transactions bloquées ?
Notre problème ne semble pas corrélé avec l'introduction des XA car il n'est pas apparus directement dans la version applicative d'introduction des XA, mais à la version suivante.


© PostgreSQLFr, tous droits réservés.
Site déclaré à la CNIL sous le numéro 1074678, conformément à la Loi en vigueur.