[THIN] Re: Locked files in FoxPro published applications
- From: "Cwalinski, Zygmunt" <zcwalinski@xxxxxxxxxxxxx>
- To: <thin@xxxxxxxxxxxxx>
- Date: Wed, 12 Sep 2007 09:44:32 -0400
Rick,
Thanks a lot for your great input. I will of course give it a try and
let you know if it helps in few days.
Zygmunt Cwalinski
Systems Analyst, Citrix and Terminal Services Network Services,
Infrastructure Support, IT Metroland Media Group Ltd.
e-mail: ZCwalinski@xxxxxxxxxxxxx <mailto:ZCwalinski@xxxxxxxxxxxxx>
phone: (905) 281-5583
________________________________
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On
Behalf Of Rick Mack
Sent: 12-09-2007 7:36 AM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Locked files in FoxPro published applications
Hi Zygmunt,
Sorry for the late entry into this thread, I've been kind of busy on a
site with no internet access.
The multi-user data structure fix was originally introduced with NT 4.0
TSE (MultipleUsersOnConnection) because there was a limit of 2048 SMB
file handles per connection or server. As an example, the 2048 file
handle limit could cause problems with Foxpro (kb219956) and other
applications. Enabling multiuser data structures (kb190162) increased
that limit to 2048 SMB file handles and a separate TCP SMB connection
per-user. It was great for improving SMB performance if you had SAMBA as
a file server.
Windows 2000 increased the SMB file handles per server to 4K (I think)
and Windows Server 2003 to 16K (kb913835). In both cases this was done
by enabling per-user SMB sessions. But it's important to remember that
on x86, enabling multiuser data structures also reduces the amount of
available kernel memory which could very well have an effect on your
server scalability.
I'd actually try disabling oplocks (opportunistic locking) first
(kb296264). Disabling oplocks certainly used to get rid of file sharing
and other locking errors with Great Plains and other applications. If
that doesn't have the desired effect, then enable per-user data
structures.
regards,
Rick
--
Ulrich Mack
www.commander.com
Other related posts:
