Hibernate utilise-t-il un verrouillage pessimiste ou optimiste?
Toutes mes classes ont un
@Version
annotation, donc j'ai supposé qu'ils utilisaient un verrouillage optimiste.
Mais, dans mes journaux, l’exception suivante semble indiquer que Im utilise un verrouillage pessimiste. Alors c'est quoi? (Je veux utiliser le verrouillage optimiste)
update Song set acoustidFingerprint=?, acoustidId=?, album=?, albumArtist=?, albumArtistSort=?, albumSort=?, amazonId=?, arranger=?, artist=?, artistSort=?, artists=?, barcode=?, bpm=?, catalogNo=?, comment=?, composer=?, composerSort=?, conductor=?, country=?, custom1=?, custom2=?, custom3=?, custom4=?, custom5=?, discNo=?, discSubtitle=?, discTotal=?, djmixer=?, duration=?, encoder=?, engineer=?, fbpm=?, filename=?, genre=?, grouping=?, isCompilation=?, isrc=?, keyOfSong=?, language=?, lastModified=?, lyricist=?, lyrics=?, media=?, mixer=?, mood=?, musicbrainzArtistId=?, musicbrainzDiscId=?, musicbrainzOriginalReleaseId=?, musicbrainzRecordingId=?, musicbrainzReleaseArtistId=?, musicbrainzReleaseCountry=?, musicbrainzReleaseGroupId=?, musicbrainzReleaseId=?, musicbrainzReleaseStatus=?, musicbrainzReleaseType=?, musicbrainzWorkId=?, musicipId=?, occasion=?, originalAlbum=?, originalArtist=?, originalLyricist=?, originalYear=?, producer=?, quality=?, rating=?, recordLabel=?, releaseYear=?, remixer=?, script=?, subtitle=?, tags=?, tempo=?, title=?, titleSort=?, track=?, trackTotal=?, urlDiscogsArtistSite=?, urlDiscogsReleaseSite=?, urlLyricsSite=?, urlOfficialArtistSite=?, urlOfficialReleaseSite=?, urlWikipediaArtistSite=?, urlWikipediaReleaseSite=?, version=? where recNo=? and version=? [50200-172]
**org.hibernate.PessimisticLockException: Timeout trying to lock table ; SQL statement:**
update Song set acoustidFingerprint=?, acoustidId=?, album=?, albumArtist=?, albumArtistSort=?, albumSort=?, amazonId=?, arranger=?, artist=?, artistSort=?, artists=?, barcode=?, bpm=?, catalogNo=?, comment=?, composer=?, composerSort=?, conductor=?, country=?, custom1=?, custom2=?, custom3=?, custom4=?, custom5=?, discNo=?, discSubtitle=?, discTotal=?, djmixer=?, duration=?, encoder=?, engineer=?, fbpm=?, filename=?, genre=?, grouping=?, isCompilation=?, isrc=?, keyOfSong=?, language=?, lastModified=?, lyricist=?, lyrics=?, media=?, mixer=?, mood=?, musicbrainzArtistId=?, musicbrainzDiscId=?, musicbrainzOriginalReleaseId=?, musicbrainzRecordingId=?, musicbrainzReleaseArtistId=?, musicbrainzReleaseCountry=?, musicbrainzReleaseGroupId=?, musicbrainzReleaseId=?, musicbrainzReleaseStatus=?, musicbrainzReleaseType=?, musicbrainzWorkId=?, musicipId=?, occasion=?, originalAlbum=?, originalArtist=?, originalLyricist=?, originalYear=?, producer=?, quality=?, rating=?, recordLabel=?, releaseYear=?, remixer=?, script=?, subtitle=?, tags=?, tempo=?, title=?, titleSort=?, track=?, trackTotal=?, urlDiscogsArtistSite=?, urlDiscogsReleaseSite=?, urlLyricsSite=?, urlOfficialArtistSite=?, urlOfficialReleaseSite=?, urlWikipediaArtistSite=?, urlWikipediaReleaseSite=?, version=? where recNo=? and version=? [50200-172]
at org.hibernate.dialect.H2Dialect$2.convert(H2Dialect.Java:317)
at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.Java:49)
at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.Java:125)
at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.Java:110)
at org.hibernate.engine.jdbc.internal.proxy.AbstractStatementProxyHandler.continueInvocation(AbstractStatementProxyHandler.Java:129)
at org.hibernate.engine.jdbc.internal.proxy.AbstractProxyHandler.invoke(AbstractProxyHandler.Java:81)
at com.Sun.proxy.$Proxy22.executeUpdate(Unknown Source)
at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.Java:3123)
at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.Java:3021)
at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.Java:3350)
at org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.Java:140)
at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.Java:362)
at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.Java:354)
at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.Java:276)
at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.Java:326)
at org.hibernate.event.internal.DefaultAutoFlushEventListener.onAutoFlush(DefaultAutoFlushEventListener.Java:62)
at org.hibernate.internal.SessionImpl.autoFlushIfRequired(SessionImpl.Java:1182)
at org.hibernate.internal.SessionImpl.list(SessionImpl.Java:1611)
at org.hibernate.internal.CriteriaImpl.list(CriteriaImpl.Java:374)
at com.jthink.songkong.db.SongCache.loadSongsFromDatabase(SongCache.Java:58)
at com.jthink.songkong.analyse.analyser.SongGroup.getSongs(SongGroup.Java:48)
at com.jthink.songkong.analyse.analyser.MergeMusicBrainzMatches.matchToMissingTracks(MergeMusicBrainzMatches.Java:318)
at com.jthink.songkong.analyse.analyser.MergeMusicBrainzMatches.call(MergeMusicBrainzMatches.Java:105)
at com.jthink.songkong.analyse.analyser.MergeMusicBrainzMatches.call(MergeMusicBrainzMatches.Java:40)
at Java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.Java:334)
at Java.util.concurrent.FutureTask.run(FutureTask.Java:166)
at Java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.Java:1145)
at Java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.Java:615)
at Java.lang.Thread.run(Thread.Java:722)
Caused by: org.h2.jdbc.JdbcSQLException: Timeout trying to lock table ; SQL statement:
update Song set acoustidFingerprint=?, acoustidId=?, album=?, albumArtist=?, albumArtistSort=?, albumSort=?, amazonId=?, arranger=?, artist=?, artistSort=?, artists=?, barcode=?, bpm=?, catalogNo=?, comment=?, composer=?, composerSort=?, conductor=?, country=?, custom1=?, custom2=?, custom3=?, custom4=?, custom5=?, discNo=?, discSubtitle=?, discTotal=?, djmixer=?, duration=?, encoder=?, engineer=?, fbpm=?, filename=?, genre=?, grouping=?, isCompilation=?, isrc=?, keyOfSong=?, language=?, lastModified=?, lyricist=?, lyrics=?, media=?, mixer=?, mood=?, musicbrainzArtistId=?, musicbrainzDiscId=?, musicbrainzOriginalReleaseId=?, musicbrainzRecordingId=?, musicbrainzReleaseArtistId=?, musicbrainzReleaseCountry=?, musicbrainzReleaseGroupId=?, musicbrainzReleaseId=?, musicbrainzReleaseStatus=?, musicbrainzReleaseType=?, musicbrainzWorkId=?, musicipId=?, occasion=?, originalAlbum=?, originalArtist=?, originalLyricist=?, originalYear=?, producer=?, quality=?, rating=?, recordLabel=?, releaseYear=?, remixer=?, script=?, subtitle=?, tags=?, tempo=?, title=?, titleSort=?, track=?, trackTotal=?, urlDiscogsArtistSite=?, urlDiscogsReleaseSite=?, urlLyricsSite=?, urlOfficialArtistSite=?, urlOfficialReleaseSite=?, urlWikipediaArtistSite=?, urlWikipediaReleaseSite=?, version=? where recNo=? and version=? [50200-172]
at org.h2.message.DbException.getJdbcSQLException(DbException.Java:329)
at org.h2.message.DbException.get(DbException.Java:158)
at org.h2.command.Command.filterConcurrentUpdate(Command.Java:281)
at org.h2.command.Command.executeUpdate(Command.Java:237)
at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.Java:154)
at org.h2.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.Java:140)
at com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.executeUpdate(NewProxyPreparedStatement.Java:105)
at Sun.reflect.GeneratedMethodAccessor55.invoke(Unknown Source)
at Sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.Java:43)
at Java.lang.reflect.Method.invoke(Method.Java:601)
at org.hibernate.engine.jdbc.internal.proxy.AbstractStatementProxyHandler.continueInvocation(AbstractStatementProxyHandler.Java:122)
... 24 more
Vous utilisez verrouillage optimiste } _, comme l'indique votre instruction UPDATE:
where recNo=? and version=?
La présence de la colonne version est ce qu’est le verrouillage optimiste.
Vous avez été induit en erreur par la variable PessimisticLockException qui pourrait être provoquée par un verrou explicite ou implicite au niveau de la ligne }.
Vous devez comprendre que les verrous sont acquis de manière implicite sur les lignes pour éviter les écritures incorrectes. Ce livre explique cette rubrique avec de nombreux diagrammes et exemples de code.
Cette exception est due à Lock TimeOut.
Causée par: org.h2.jdbc.JdbcSQLException: expiration du délai pour tenter de verrouiller la table;
Vérifier une solution here
Hibernate fournit également des mécanismes pour implémenter les deux types de verrouillage dans vos applications.
Votre stratégie de verrouillage peut être optimiste ou pessimiste.
Optimiste
Le verrouillage optimiste suppose que plusieurs transactions peuvent se terminer sans s’affecter et que, par conséquent, les transactions peuvent continuer sans verrouiller les ressources de données qu’elles affectent. Avant de valider, chaque transaction vérifie qu'aucune autre transaction n'a modifié ses données. Si la vérification révèle des modifications contradictoires, la transaction validée est annulée [1].
Pessimiste
Le verrouillage pessimiste suppose que les transactions simultanées sont en conflit et nécessite que les ressources soient verrouillées après leur lecture et déverrouillées une fois que l'application a fini d'utiliser les données.
Les détails peuvent être trouvés here
Il est fort probable que vous utiliserez pour le test une base de données différente de celle utilisée dans l'environnement LIVE.
H2 peut produire des erreurs, qui pourraient ne pas apparaître sur la base de données LIVE comme Oracle, MySQL a.s.o .. signifie que même votre code est correct, mais le H2 peut éventuellement être dérangeant.
Le MVCC = true fonctionne parfaitement. Dans le même temps, vous devez vous assurer que vous avez des tests d'intégration complets sur LIVE, comme les systèmes, pour votre cas d'utilisation, afin de vérifier le comportement de la base de données LIVE.