From: cremor (JIRA) <nh...@gm...> - 2011-02-03 12:36:32
|
AbstractBatcher reuses disposed IDbCommands which causes an ArgumentOutOfRangeException with OracleDataClientDriver ------------------------------------------------------------------------------------------------------------------- Key: NH-2527 URL: http://216.121.112.228/browse/NH-2527 Project: NHibernate Issue Type: Bug Components: Core Affects Versions: 3.0.0.GA Reporter: cremor Priority: Critical The attached test shows that the AbstractBatcher reuses already disposed IDbCommands in some cases (in my case, when an OneToMany entry is inserted and updated in the same commit). This seems to be no problem with some (most?) drivers (I tested SQLite20Driver and OracleClientDriver, both had no problems) but causes an ArgumentOutOfRangeException with the OracleDataClientDriver because the Parameters collection is empty. The dispose is called from AbstractBatcher.CloseCommand() which is called from OneToManyPersister.DoUpdateRows(). AbstractBatcher.CloseCommand() checks if 'lastQuery' is the just disposed command and if yes clears it, but doesn't check 'batchCommand'. (Possible fix by calling InvalidateBatchCommand() if batchCommand == cmd.) Seems like a similar problem was already fixed for Firebird because the method AbstractBatcher.PrepareBatchCommand() checks for an empty CommandText and the comment says that it's unknown why it's empty sometimes. (Other possible fix by comparing batchCommand.Parameters.Count and parameterTypes.Length.) I don't know which of the two fixes would be better (or if there is an even better fix), therefore I didn't create a patch. Please note that even with one of the two fixes, the test still fails (with an StaleStateException) if you don't set adonet.batch_size to 0. I don't know why it doesn't work with batching, but this seems like a different bug. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: cremor (JIRA) <nh...@gm...> - 2011-02-03 12:41:27
|
[ http://216.121.112.228/browse/NH-2527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] cremor updated NH-2527: ----------------------- Attachment: NH2527 Test.zip > AbstractBatcher reuses disposed IDbCommands which causes an ArgumentOutOfRangeException with OracleDataClientDriver > ------------------------------------------------------------------------------------------------------------------- > > Key: NH-2527 > URL: http://216.121.112.228/browse/NH-2527 > Project: NHibernate > Issue Type: Bug > Components: Core > Affects Versions: 3.0.0.GA > Reporter: cremor > Priority: Critical > Attachments: NH2527 Test.zip > > > The attached test shows that the AbstractBatcher reuses already disposed IDbCommands in some cases (in my case, when an OneToMany entry is inserted and updated in the same commit). This seems to be no problem with some (most?) drivers (I tested SQLite20Driver and OracleClientDriver, both had no problems) but causes an ArgumentOutOfRangeException with the OracleDataClientDriver because the Parameters collection is empty. > The dispose is called from AbstractBatcher.CloseCommand() which is called from OneToManyPersister.DoUpdateRows(). > AbstractBatcher.CloseCommand() checks if 'lastQuery' is the just disposed command and if yes clears it, but doesn't check 'batchCommand'. (Possible fix by calling InvalidateBatchCommand() if batchCommand == cmd.) > Seems like a similar problem was already fixed for Firebird because the method AbstractBatcher.PrepareBatchCommand() checks for an empty CommandText and the comment says that it's unknown why it's empty sometimes. (Other possible fix by comparing batchCommand.Parameters.Count and parameterTypes.Length.) > I don't know which of the two fixes would be better (or if there is an even better fix), therefore I didn't create a patch. > Please note that even with one of the two fixes, the test still fails (with an StaleStateException) if you don't set adonet.batch_size to 0. I don't know why it doesn't work with batching, but this seems like a different bug. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: cremor (JIRA) <nh...@gm...> - 2011-02-28 07:38:19
|
[ http://216.121.112.228/browse/NH-2527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20601#action_20601 ] cremor commented on NH-2527: ---------------------------- Any chance that this will be fixed in 3.1.0? Or isn't it as easy to fix as I proposed? > AbstractBatcher reuses disposed IDbCommands which causes an ArgumentOutOfRangeException with OracleDataClientDriver > ------------------------------------------------------------------------------------------------------------------- > > Key: NH-2527 > URL: http://216.121.112.228/browse/NH-2527 > Project: NHibernate > Issue Type: Bug > Components: Core > Affects Versions: 3.0.0.GA > Reporter: cremor > Priority: Critical > Attachments: NH2527 Test.zip > > > The attached test shows that the AbstractBatcher reuses already disposed IDbCommands in some cases (in my case, when an OneToMany entry is inserted and updated in the same commit). This seems to be no problem with some (most?) drivers (I tested SQLite20Driver and OracleClientDriver, both had no problems) but causes an ArgumentOutOfRangeException with the OracleDataClientDriver because the Parameters collection is empty. > The dispose is called from AbstractBatcher.CloseCommand() which is called from OneToManyPersister.DoUpdateRows(). > AbstractBatcher.CloseCommand() checks if 'lastQuery' is the just disposed command and if yes clears it, but doesn't check 'batchCommand'. (Possible fix by calling InvalidateBatchCommand() if batchCommand == cmd.) > Seems like a similar problem was already fixed for Firebird because the method AbstractBatcher.PrepareBatchCommand() checks for an empty CommandText and the comment says that it's unknown why it's empty sometimes. (Other possible fix by comparing batchCommand.Parameters.Count and parameterTypes.Length.) > I don't know which of the two fixes would be better (or if there is an even better fix), therefore I didn't create a patch. > Please note that even with one of the two fixes, the test still fails (with an StaleStateException) if you don't set adonet.batch_size to 0. I don't know why it doesn't work with batching, but this seems like a different bug. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Fabio M. (JIRA) <nh...@gm...> - 2011-03-24 20:51:05
|
[ http://216.121.112.228/browse/NH-2527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20730#action_20730 ] Fabio Maulo commented on NH-2527: --------------------------------- Which batcher are you using ? Are you using the OracleDataClientBatchingBatcher or the NonBatchingBatcher ? > AbstractBatcher reuses disposed IDbCommands which causes an ArgumentOutOfRangeException with OracleDataClientDriver > ------------------------------------------------------------------------------------------------------------------- > > Key: NH-2527 > URL: http://216.121.112.228/browse/NH-2527 > Project: NHibernate > Issue Type: Bug > Components: Core > Affects Versions: 3.0.0.GA > Reporter: cremor > Priority: Critical > Attachments: NH2527 Test.zip > > > The attached test shows that the AbstractBatcher reuses already disposed IDbCommands in some cases (in my case, when an OneToMany entry is inserted and updated in the same commit). This seems to be no problem with some (most?) drivers (I tested SQLite20Driver and OracleClientDriver, both had no problems) but causes an ArgumentOutOfRangeException with the OracleDataClientDriver because the Parameters collection is empty. > The dispose is called from AbstractBatcher.CloseCommand() which is called from OneToManyPersister.DoUpdateRows(). > AbstractBatcher.CloseCommand() checks if 'lastQuery' is the just disposed command and if yes clears it, but doesn't check 'batchCommand'. (Possible fix by calling InvalidateBatchCommand() if batchCommand == cmd.) > Seems like a similar problem was already fixed for Firebird because the method AbstractBatcher.PrepareBatchCommand() checks for an empty CommandText and the comment says that it's unknown why it's empty sometimes. (Other possible fix by comparing batchCommand.Parameters.Count and parameterTypes.Length.) > I don't know which of the two fixes would be better (or if there is an even better fix), therefore I didn't create a patch. > Please note that even with one of the two fixes, the test still fails (with an StaleStateException) if you don't set adonet.batch_size to 0. I don't know why it doesn't work with batching, but this seems like a different bug. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Fabio M. (JIRA) <nh...@gm...> - 2011-03-24 21:11:03
|
[ http://216.121.112.228/browse/NH-2527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20731#action_20731 ] Fabio Maulo commented on NH-2527: --------------------------------- The test does not fail neither using our SqlClientBatchingBatcher nor using NonBatchingBatcher. Test commited in our source and needs to be checked with OracleDataClientDriver. > AbstractBatcher reuses disposed IDbCommands which causes an ArgumentOutOfRangeException with OracleDataClientDriver > ------------------------------------------------------------------------------------------------------------------- > > Key: NH-2527 > URL: http://216.121.112.228/browse/NH-2527 > Project: NHibernate > Issue Type: Bug > Components: Core > Affects Versions: 3.0.0.GA > Reporter: cremor > Priority: Critical > Attachments: NH2527 Test.zip > > > The attached test shows that the AbstractBatcher reuses already disposed IDbCommands in some cases (in my case, when an OneToMany entry is inserted and updated in the same commit). This seems to be no problem with some (most?) drivers (I tested SQLite20Driver and OracleClientDriver, both had no problems) but causes an ArgumentOutOfRangeException with the OracleDataClientDriver because the Parameters collection is empty. > The dispose is called from AbstractBatcher.CloseCommand() which is called from OneToManyPersister.DoUpdateRows(). > AbstractBatcher.CloseCommand() checks if 'lastQuery' is the just disposed command and if yes clears it, but doesn't check 'batchCommand'. (Possible fix by calling InvalidateBatchCommand() if batchCommand == cmd.) > Seems like a similar problem was already fixed for Firebird because the method AbstractBatcher.PrepareBatchCommand() checks for an empty CommandText and the comment says that it's unknown why it's empty sometimes. (Other possible fix by comparing batchCommand.Parameters.Count and parameterTypes.Length.) > I don't know which of the two fixes would be better (or if there is an even better fix), therefore I didn't create a patch. > Please note that even with one of the two fixes, the test still fails (with an StaleStateException) if you don't set adonet.batch_size to 0. I don't know why it doesn't work with batching, but this seems like a different bug. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: cremor (JIRA) <nh...@gm...> - 2011-03-25 06:26:05
|
[ http://216.121.112.228/browse/NH-2527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20735#action_20735 ] cremor commented on NH-2527: ---------------------------- I'm using the NonBatchingBatcher. As I have written above, if the Oracle Batcher is used, another bug seems to occur. And yes, it seems like most drivers can work with an already disposed DbCommand, but the OracleDataClientDriver doesn't (because it's clearing the Parameters collection in Dispose). > AbstractBatcher reuses disposed IDbCommands which causes an ArgumentOutOfRangeException with OracleDataClientDriver > ------------------------------------------------------------------------------------------------------------------- > > Key: NH-2527 > URL: http://216.121.112.228/browse/NH-2527 > Project: NHibernate > Issue Type: Bug > Components: Core > Affects Versions: 3.0.0.GA > Reporter: cremor > Priority: Critical > Attachments: NH2527 Test.zip > > > The attached test shows that the AbstractBatcher reuses already disposed IDbCommands in some cases (in my case, when an OneToMany entry is inserted and updated in the same commit). This seems to be no problem with some (most?) drivers (I tested SQLite20Driver and OracleClientDriver, both had no problems) but causes an ArgumentOutOfRangeException with the OracleDataClientDriver because the Parameters collection is empty. > The dispose is called from AbstractBatcher.CloseCommand() which is called from OneToManyPersister.DoUpdateRows(). > AbstractBatcher.CloseCommand() checks if 'lastQuery' is the just disposed command and if yes clears it, but doesn't check 'batchCommand'. (Possible fix by calling InvalidateBatchCommand() if batchCommand == cmd.) > Seems like a similar problem was already fixed for Firebird because the method AbstractBatcher.PrepareBatchCommand() checks for an empty CommandText and the comment says that it's unknown why it's empty sometimes. (Other possible fix by comparing batchCommand.Parameters.Count and parameterTypes.Length.) > I don't know which of the two fixes would be better (or if there is an even better fix), therefore I didn't create a patch. > Please note that even with one of the two fixes, the test still fails (with an StaleStateException) if you don't set adonet.batch_size to 0. I don't know why it doesn't work with batching, but this seems like a different bug. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: cremor (JIRA) <nh...@gm...> - 2011-04-05 06:59:40
|
[ http://216.121.112.228/browse/NH-2527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] cremor updated NH-2527: ----------------------- Attachment: NH2527 Additional Test.zip Here is an additional test that should show the bug with all drivers. > AbstractBatcher reuses disposed IDbCommands which causes an ArgumentOutOfRangeException with OracleDataClientDriver > ------------------------------------------------------------------------------------------------------------------- > > Key: NH-2527 > URL: http://216.121.112.228/browse/NH-2527 > Project: NHibernate > Issue Type: Bug > Components: Core > Affects Versions: 3.0.0.GA > Reporter: cremor > Priority: Critical > Attachments: NH2527 Additional Test.zip, NH2527 Test.zip > > > The attached test shows that the AbstractBatcher reuses already disposed IDbCommands in some cases (in my case, when an OneToMany entry is inserted and updated in the same commit). This seems to be no problem with some (most?) drivers (I tested SQLite20Driver and OracleClientDriver, both had no problems) but causes an ArgumentOutOfRangeException with the OracleDataClientDriver because the Parameters collection is empty. > The dispose is called from AbstractBatcher.CloseCommand() which is called from OneToManyPersister.DoUpdateRows(). > AbstractBatcher.CloseCommand() checks if 'lastQuery' is the just disposed command and if yes clears it, but doesn't check 'batchCommand'. (Possible fix by calling InvalidateBatchCommand() if batchCommand == cmd.) > Seems like a similar problem was already fixed for Firebird because the method AbstractBatcher.PrepareBatchCommand() checks for an empty CommandText and the comment says that it's unknown why it's empty sometimes. (Other possible fix by comparing batchCommand.Parameters.Count and parameterTypes.Length.) > I don't know which of the two fixes would be better (or if there is an even better fix), therefore I didn't create a patch. > Please note that even with one of the two fixes, the test still fails (with an StaleStateException) if you don't set adonet.batch_size to 0. I don't know why it doesn't work with batching, but this seems like a different bug. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: cremor (JIRA) <nh...@gm...> - 2011-04-05 07:04:52
|
[ http://216.121.112.228/browse/NH-2527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20829#action_20829 ] cremor commented on NH-2527: ---------------------------- Sorry for the last comment, that was wrong. It doesn't work for all drivers since it subclasses the SQLite20Driver, but you should see the bug now with SQLite. > AbstractBatcher reuses disposed IDbCommands which causes an ArgumentOutOfRangeException with OracleDataClientDriver > ------------------------------------------------------------------------------------------------------------------- > > Key: NH-2527 > URL: http://216.121.112.228/browse/NH-2527 > Project: NHibernate > Issue Type: Bug > Components: Core > Affects Versions: 3.0.0.GA > Reporter: cremor > Priority: Critical > Attachments: NH2527 Additional Test.zip, NH2527 Test.zip > > > The attached test shows that the AbstractBatcher reuses already disposed IDbCommands in some cases (in my case, when an OneToMany entry is inserted and updated in the same commit). This seems to be no problem with some (most?) drivers (I tested SQLite20Driver and OracleClientDriver, both had no problems) but causes an ArgumentOutOfRangeException with the OracleDataClientDriver because the Parameters collection is empty. > The dispose is called from AbstractBatcher.CloseCommand() which is called from OneToManyPersister.DoUpdateRows(). > AbstractBatcher.CloseCommand() checks if 'lastQuery' is the just disposed command and if yes clears it, but doesn't check 'batchCommand'. (Possible fix by calling InvalidateBatchCommand() if batchCommand == cmd.) > Seems like a similar problem was already fixed for Firebird because the method AbstractBatcher.PrepareBatchCommand() checks for an empty CommandText and the comment says that it's unknown why it's empty sometimes. (Other possible fix by comparing batchCommand.Parameters.Count and parameterTypes.Length.) > I don't know which of the two fixes would be better (or if there is an even better fix), therefore I didn't create a patch. > Please note that even with one of the two fixes, the test still fails (with an StaleStateException) if you don't set adonet.batch_size to 0. I don't know why it doesn't work with batching, but this seems like a different bug. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: cremor (JIRA) <nh...@gm...> - 2011-05-05 10:33:02
|
[ http://216.121.112.228/browse/NH-2527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20998#action_20998 ] cremor commented on NH-2527: ---------------------------- Is there anything else I can provide to help fixing this? > AbstractBatcher reuses disposed IDbCommands which causes an ArgumentOutOfRangeException with OracleDataClientDriver > ------------------------------------------------------------------------------------------------------------------- > > Key: NH-2527 > URL: http://216.121.112.228/browse/NH-2527 > Project: NHibernate > Issue Type: Bug > Components: Core > Affects Versions: 3.0.0.GA > Reporter: cremor > Priority: Critical > Attachments: NH2527 Additional Test.zip, NH2527 Test.zip > > > The attached test shows that the AbstractBatcher reuses already disposed IDbCommands in some cases (in my case, when an OneToMany entry is inserted and updated in the same commit). This seems to be no problem with some (most?) drivers (I tested SQLite20Driver and OracleClientDriver, both had no problems) but causes an ArgumentOutOfRangeException with the OracleDataClientDriver because the Parameters collection is empty. > The dispose is called from AbstractBatcher.CloseCommand() which is called from OneToManyPersister.DoUpdateRows(). > AbstractBatcher.CloseCommand() checks if 'lastQuery' is the just disposed command and if yes clears it, but doesn't check 'batchCommand'. (Possible fix by calling InvalidateBatchCommand() if batchCommand == cmd.) > Seems like a similar problem was already fixed for Firebird because the method AbstractBatcher.PrepareBatchCommand() checks for an empty CommandText and the comment says that it's unknown why it's empty sometimes. (Other possible fix by comparing batchCommand.Parameters.Count and parameterTypes.Length.) > I don't know which of the two fixes would be better (or if there is an even better fix), therefore I didn't create a patch. > Please note that even with one of the two fixes, the test still fails (with an StaleStateException) if you don't set adonet.batch_size to 0. I don't know why it doesn't work with batching, but this seems like a different bug. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Fabio M. (JIRA) <nh...@gm...> - 2011-05-10 18:31:51
|
[ http://216.121.112.228/browse/NH-2527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fabio Maulo updated NH-2527: ---------------------------- Priority: Minor (was: Critical) > AbstractBatcher reuses disposed IDbCommands which causes an ArgumentOutOfRangeException with OracleDataClientDriver > ------------------------------------------------------------------------------------------------------------------- > > Key: NH-2527 > URL: http://216.121.112.228/browse/NH-2527 > Project: NHibernate > Issue Type: Bug > Components: Core > Affects Versions: 3.0.0.GA > Reporter: cremor > Priority: Minor > Attachments: NH2527 Additional Test.zip, NH2527 Test.zip > > > The attached test shows that the AbstractBatcher reuses already disposed IDbCommands in some cases (in my case, when an OneToMany entry is inserted and updated in the same commit). This seems to be no problem with some (most?) drivers (I tested SQLite20Driver and OracleClientDriver, both had no problems) but causes an ArgumentOutOfRangeException with the OracleDataClientDriver because the Parameters collection is empty. > The dispose is called from AbstractBatcher.CloseCommand() which is called from OneToManyPersister.DoUpdateRows(). > AbstractBatcher.CloseCommand() checks if 'lastQuery' is the just disposed command and if yes clears it, but doesn't check 'batchCommand'. (Possible fix by calling InvalidateBatchCommand() if batchCommand == cmd.) > Seems like a similar problem was already fixed for Firebird because the method AbstractBatcher.PrepareBatchCommand() checks for an empty CommandText and the comment says that it's unknown why it's empty sometimes. (Other possible fix by comparing batchCommand.Parameters.Count and parameterTypes.Length.) > I don't know which of the two fixes would be better (or if there is an even better fix), therefore I didn't create a patch. > Please note that even with one of the two fixes, the test still fails (with an StaleStateException) if you don't set adonet.batch_size to 0. I don't know why it doesn't work with batching, but this seems like a different bug. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |