[JIRA] Commented: (SSPCPP-507) Insert record failed Violation of PRIMARY KEY constraint with ODBC plugin
Scott Cantor (JIRA)
noreply at shibboleth.net
Thu Oct 4 00:01:21 EDT 2012
[ https://issues.shibboleth.net/jira/browse/SSPCPP-507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14447#comment-14447 ]
Scott Cantor commented on SSPCPP-507:
-------------------------------------
I always miss the attachment in Jira, sorry. ;-(
So it's looping, obviously, and probably appearing to hang shibd? I'm not sure why that is. It appears to be colliding with an inserted record behind it, but not seeing that record when the retry logic attempts to read the record that it collided with.
I can't really make it see the record if the database won't return it. Any open transaction autocommits as soon as the operation completes and the connection is closed, if it's working as intended, so it should see the inserted record behind it on at least some subsequent trip through the loop.
Other than implementing a block on the recursion to prevent it from being broken by a database that's refusing to work, I don't know what else to do. That much is obviously needed.
My guess is there's something preventing the transaction that inserted the original record from completing or something, and it's not visible to the select statement on the other node, but it's enough to block the insert. I set autocommit on when I create the connections, so other than that, I don't know what I can do to get the record to get committed and show up.
I'll also add error checking to deal with the version overflow, but in practice that's not a major concern.
> Insert record failed Violation of PRIMARY KEY constraint with ODBC plugin
> -------------------------------------------------------------------------
>
> Key: SSPCPP-507
> URL: https://issues.shibboleth.net/jira/browse/SSPCPP-507
> Project: Shibboleth SP - C++
> Issue Type: Bug
> Security Level: Standard(Standard bug, may impact functionality but does not represent a security vulnerability )
> Components: Session Cache
> Affects Versions: 2.5.0
> Environment: Windows 2008 R2 on Azure.
> Reporter: pbrears at idp.protectnetwork.org
> Assignee: Scott Cantor
> Labels: Session
> Attachments: shiblogs.zip
>
>
> Using two servers with the odbc connection plugin for the storage service you can occasionally get 'insert record failed' 'Violation of PRIMARY KEY constraint' logged
> We're using "SQL Server Native Client 10.0" driver to access SQL azure for the db
> There are two servers in the non sticky load balancer. It's likely that /SAML/POST and /Secure are landing on different boxes.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the commits
mailing list