Anomaly when query timeout in Data buffer

[former_member331439]

Hello experts

I'm using MII12.2 and query buffered (allow buffering flag) on a database with several tables locks.

When I get a query timeout (LastErrorMessage of the query is "Response timed out, request terminated"), the query is not queued in the buffer.

Just if I send the query to the buffer setting a wrong used id in the dataserver, then the manager works properly (when I restore the used id, the query completes its logic when the lock is released)

If anybody wants to replicate the enviroment, the query for table lock in SQL Server is

     BEGIN TRANSACTION

     SELECT * FROM [your table name] WITH (TABLOCKX, HOLDLOCK);

     WAITFOR DELAY '00:10:00'

     ROLLBACK TRANSACTION

You have to run it in SQL Manager, not in MII

Sequence:

- Create in MII a generic query with SELECT * FROM [your table name], and enable "allow buffering"

- Call it in a transaction (if you want, with exception handler)

- Run the lock query in SQL Server

- Run the transaction (while the table is locked by SQL Server query) and wait transaction/query error

- Check data buffer: the MII query is not buffered

Is it normal?

Is there any patch?

Thanks

Regards

Fabio

[Former Member]

Hi Fabio,

I think the query does not gets buffered because no communication error happened.

MII would buffer an external call if there is a communication error.

But in your case the communication happened fine and the DB did not gave the response and thus time out happened. One more scenario of this type is if we write a query with syntax error. Here also the communication will happen with the DB but the DB will give the error thus MII will not buffer the query.

Regards,

Rohit Negi.

[former_member331439]

Hello Rohit

the strange is that if the query is in resubmission for dataserver wrong parameter (username/password), when I restore the communication parameters and I leave the database locked, the query remains in pending and disappears only when I unlock the database. The behavior in this case is correct.

A query timeout for table lock (or backup in progress) is the maximum example of communication issue in my opinion: it seems strange...maybe a bug

Thanks

Regards

Fabio