Oracle-vertraging tussen commit en select

Standaard zou het door u beschreven gedrag onmogelijk moeten zijn - wijzigingen die in een vastgelegde transactie zijn aangebracht, worden onmiddellijk beschikbaar voor alle sessies. Er zijn echter uitzonderingen:

1. Gebruikt u een van de WRITE-opties in het COMMIT-commando? Als dat niet het geval is, bevestigt u de waarde van uw COMMIT_WRITE-initialisatieparameter. Als een van beide de "WRITE BATCH" of vooral "WRITE BATCH NOWAIT" gebruikt, zou je jezelf bloot kunnen stellen aan gelijktijdigheidsproblemen. "SCHRIJF BATCH NOWAIT" wordt meestal gebruikt in gevallen waarin de snelheid van uw schrijftransacties van groter belang is dan mogelijke gelijktijdigheidsproblemen. Als uw initialisatieparameter de "WRITE"-varianten gebruikt, kunt u deze op transactiebasis overschrijven door de IMMEDIATE-clausule in uw commits op te geven (zie COMMIT)

2. Wordt door de transactie die probeert de gegevens te lezen SET TRANSACTION aangeroepen voordat de andere transactie wordt uitgevoerd? Als u SET TRANSACTION gebruikt om het SERIALISATIENIVEAU ALLEEN LEZEN of SERIALISEERBAAR te specificeren, zal de transactie geen veranderingen zien die optreden van andere toegewijde sessies die plaatsvonden na het aanroepen van SET TRANSACTIE (zie TRANSACTIE INSTELLEN)

edit:ik zie dat je een DataSource-klasse gebruikt. Ik ben niet bekend met deze klasse - ik neem aan dat het een bron voor het delen van verbindingen is. Ik realiseer me dat uw huidige app-ontwerp het misschien niet gemakkelijk maakt om hetzelfde verbindingsobject in uw hele werkstroom te gebruiken (de stappen zijn mogelijk ontworpen om onafhankelijk te werken en u hebt geen mogelijkheid ingebouwd om een ​​verbindingsobject van de ene stap naar de next), maar u moet controleren of verbindingsobjecten die worden geretourneerd naar het DataSource-object "schoon" zijn, vooral met betrekking tot open transacties. Het is mogelijk dat u SET TRANSACTION niet aanroept in uw code, maar dat een andere gebruiker van DataSource dit elders wel doet, en de verbinding terugbrengt naar de gegevensbron terwijl de sessie nog in SERIALIZABLE of READ ONLY-modus is. Bij het delen van verbindingen is het absoluut noodzakelijk dat alle verbindingen worden teruggedraaid voordat ze worden overgedragen aan een nieuwe consument.

Als u geen controle of zicht hebt op het gedrag van de DataSource-klasse, kunt u proberen een ROLLBACK uit te voeren op de nieuw verworven verbinding om te verzekeren dat er geen slepende transactie al tot stand is gebracht.