Feedback
Did this article resolve your question/issue?

   

Article

Is the number of records packed into a network message affected by the use of the NO-LOCK qualifier in a query

« Go Back

Information

 
TitleIs the number of records packed into a network message affected by the use of the NO-LOCK qualifier in a query
URL NameP176713
Article Number000135904
EnvironmentProduct: Progress
Version: 9.x
Product: OpenEdge
Version: 10.x, 11.x, 12.x
OS: All supported platforms
Question/Problem Description
Is the number of records packed into a network message affected by the use of the NO-LOCK qualifier in a query?
How many records are returned in a network message sent by the server to the client?
Does -Mm affect the number of records a server will pack into a network message to be sent to a client?
Steps to Reproduce
Clarifying Information
Error Message
Defect Number
Enhancement Number
Cause
Resolution
The -Mm parameter is used to specify the standard message buffer size in bytes. OpenEdge uses message buffers to move records between servers and remote clients. The number of records that get packed into a message buffer depends on they type of query run and the size of the records. When running a query using the NO-LOCK qualifier, the first record is packed into a message buffer and sent to the client. For the remaining records, a message buffer will be packed with as many records as it can fit. The number of records that will fit in the message buffer depends on the size of the records and the value of -Mm.

However at the IP level, packet sizes are limited to the MTU for the connection which is determined by the Ethernet frame size the network interface can handle. Larger TCP message must be split into several Ethernet frames not larger than the MTU. TCP will break it up into the MTU size packets and send them out using TCP windowing.  There are some theories that -Mm should equal the MTU network setting to be as efficient as possible.
$  netsh interface show interface | find "Connected"
$  netsh interface ipv4 show subinterface

Running a query that utilizes any other type of lock other than NO-LOCK, will result in only one record per message buffer sent to the client, regardless of the -Mm startup parameter value. This is done by design, so as to minimize the number of records locked at any one time. If multiple locked records were allowed in a message this would destroy performance since everyone else would have to wait on the unnecessarily locked records in the message, until the user gets around to them on the client side where the lock releases would need to go back individually defeating the purpose of the multiple-record message.  This would also potentially cause deadlocks and other problems due to locking logic. 

To this end, consider upgrading to OpenEdge 12, which introduced the multi-threaded database model: (-threadedServer -threadedServerStack ) to handle client/server requests concurrently and server-side joins (-ssj) to further improve reducing the result set over the network for final client-side processing. Improvements for dynamic queries were added in later.
 
Workaround
Notes
Last Modified Date12/1/2020 2:49 PM
Attachment 
Files
Disclaimer The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.