Thanks for pointing to this issue.
But the method that overrides lock create statement has a bug... If
isUseLockCreateWhereClause() is true, the produced statement will look
something like this:
*SELECT * FROM ACTIVEMQ_LOCK WHERE ID=1 WITH (UPDLOCK, ROWLOCK)* which will
throw a
*/com.microsoft.sq
have a peek at https://issues.apache.org/jira/browse/AMQ-1191
On 6 July 2012 16:36, mikmela wrote:
> Have you seen this simple select *SELECT * FROM ACTIVEMQ_LOCK WHERE ID=1*
> working for MS SQL Server?
> It doesn't for me in terms of master/slave synchronization (i.e. slave is
> not blocked on
Have you seen this simple select *SELECT * FROM ACTIVEMQ_LOCK WHERE ID=1*
working for MS SQL Server?
It doesn't for me in terms of master/slave synchronization (i.e. slave is
not blocked on this select) unless I do something like this *SELECT * FROM
ACTIVEMQ_LOCK(rowlock, updlock, REPEATABLEREAD)
The lock implementation is picked up from the driver name but there is
currently no variant that does not use the "FOR UPDATE"
If one particular statement is causing problems, you can override the
default to drop the 'FOR UPDATE' using xml config:
I'm not sure if it's the specific version of SQL server that we're using, but
S*ELECT * FROM ACTIVEMQ_LOCK WHERE ID=1 FOR UPDATE* throws exception *"FOR
Update clause allowed only for DECLARE CURSOR" *...
I'm using 5.6.0 - Am I missing something in connection string or
configuration properties?
