Hi!
I'm still with this problem.
Could someone say if SequenceManagers use default connection present at
current thread?
Or it's executed inside same transaction (I don't know if this implies
same connection)?
Thanks for any clarifications!
Richter
Edson Carlos Ericksson Richter escreveu:
Armin Waibel escreveu:
Hi,
I'm not a database expert, so please forbear with me ;-)
Edson Carlos Ericksson Richter wrote:
Hi!
There is a very long time since my last problem with OJB - thank you
guys, it's awesome how good work was done until now.
In last month, I was migrating from Oracle to MS SQL, and changed
from Sequence Manager Oracle native to Procedure based on MS SQL.
Worked great on tests, but when in production, sometimes procedure
returns same value for two users, overriding content of child tables
(it override child tables, then throw duplicate primary key
exception for parent table but changes on child tables are not being
rolled back).
Are you sure that the changes written to database or could it be a
caching problem?
Well, independent of being a cache problem, I gettin records
overwritten, what is bad per se.
I'm sure I'm beginning and rollbacking transactions, and opening and
closing connections (i never had this problem with Oracle, by example).
Did you made concurrency tests against
SequenceManagerStoredProcedureImpl? In OJB test-suite you can find a
test case called SequenceManagerTest. This test case include
concurrency sequence generation tests.
Is the issue reproduceable via unit tests?
No, I've made no tests... I tried community before (withou much luck,
until now :D )
In SequenceManagerStoredProcedureImpl source code I can't find
critical sections. So I assume it's a MSSQL concurrency problem. Does
UPDATE OJB_NEXTVAL_SEQ...
exclusive lock the table row?
Well, I was supposing it is. But after reading SP4 fixlist for
SQL2000, I start having doubts... So, I'll try to increase to
REPETEABLE READ as default transaction level, and see what happens
(god save our souls, because REPETEABLE READ almost always gives
problems of deadlocking with SQL Server).
I appreciate your comments, and I'll expect sequence gerenator author
give some comments (I really appreciate if thats possible)...
Thanks,
Edson Richter
------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]