Session Pooling and RollbackOnDisconnect

gtswim

Member
I noticed while testing that if pooling is set to spInternal and RollbackOnDisconnect is set to True that the LogOff procedure doesn't perform the rollback. If I set the pooling to spNone then LogOff does perform the rollback.

That sounds backwards to me. I would think that it is imperative that a rollback be performed if you are using a pooled connection since you don't want the next guy that uses your session to commit data that you changed.

1. Any ideas as to why this is?

2. Would it hurt us to remove the "not Shared" check prior to the Rollback in the LogOff procedure in Oracle.pas?

Thanks,
Duane
 
Transaction control is of course essential when sharing a session. You must make sure that your application ends the transaction before the session is released into the pool (Logged off).

It will not harm if you remove the check though.
 
Hi,

I also consider this a real problem and we actually had this problem in our application.

If the program terminates unexpectedly due to an error, the data is written into the database although RollbackOnDisconnect is set to true.

Is there anything you plan to do about this?

kindly regards,

Matt
 
We do have plans to change this, but if the program crashes, transactions will be rolled back. The problem can only occur if the program terminates and properly frees sessions and pools. Open transactions in pooled sessions will be committed in this case, but you still have control.
 
We've fixed the problem using the BeforeRelease-Event of the global session pool (oracle.sessionpool).

procedure TMyClass.Initialize;
begin
Oracle.SessionPool.PoolType:=ptOracle;
Oracle.SessionPool.BeforeRelease:=SessionPoolBeforeRelease;
end;

procedure TMyClass.SessionPoolBeforeRelease(Sender: TOracleSessionPool; Session: TOracleSession);
begin
Session.Rollback;
end;

Is this a appropriate solution in your opinion?

thanks,

Matt
 
Back
Top