T
Toni Van Remortel
Guest
Re: Application caching
Hi TP,
Thanks for the explanation, that makes much sense.
When we have an update again, I'll try to see what will happen on the
Terminal Server.
BTW: on the current project, we update the application in the users night
(we are in Belgium, Terminal Server is in Malaysia for users in Singapore).
Regards,
Toni
TP wrote:
> Hi Tony,
>
> First, recognize that by breaking the locking contract you
> are asking for unpredicatable behavior by definition. In
> some cases you may be happy with the results, in other
> cases you may not.
>
> One difference between the workstations and the TS is
> that you are not opening multiple instances of the exe
> at the same time on each workstation.
>
> My guesspectation as to the behavior of the TS (in your
> scenario) would be at a minimum *all* instances of the exe
> would need to be terminated before the new app version
> would load. This makes sense because the exe is in the
> cache *once* and used by the different sessions.
>
> Did you verify via Task Manager that there were no
> instances of the exe still loaded in memory? A user could
> close the app properly but it still remain running with no
> visible window. If they logout the instance would terminate.
>
> Did you use Process Explorer to verify that there were
> no open file handles to the exe on the NAS (after all
> instances were terminated)?
>
> One thing I would suggest is to create unique shares for
> each TS user/session (I assume you are limiting each user
> to one session). Each TS user would run the exe from
> their unique share name instead of using the same share
> name as the other sessions.
>
> All of the shares would in reality point to the same folder
> with the same exe. The key difference is that windows
> would treat them as unique files. Keep in mind this will
> increase the memory use on the TS.
>
> Please let us know what you work out.
>
> Thanks.
>
> -TP
>
> Toni Van Remortel wrote:
>> Hi TP,
>>
>> Thanks for your explanation about the locking mechanism. I know this
>> method, and I'm aware of it's function.
>> We do go around the locking of the exe on Linux to make our lives
>> easier (just send a mail to the users telling them to restart the app
>> when they want to, to get the new version). It works perfectly in a
>> workstation environment.
>>
>> But that still doesn't explain why the old app is openend on the
>> Terminal Server if ALL TS users have closed it. It only disappears
>> when ALL TS users log out of TS (while workstation users don't need
>> to log out to get the new app, tehy only need to close it and reopen
>> it).
>> That is my concern. If nobody has the app open, why is the old app
>> still coming back?
>>
>> In my view, there is no difference between a single workstation and a
>> Terminal Server. If every TS users closes the app, it should resemble
>> the same situation as if the workstation user closes the app. I have
>> no clue why Terminal Server would keep the old app in memory, while a
>> workstation doesn't.
>>
>> Regards,
>> Toni
--
Regards,
Toni Van Remortel
Hi TP,
Thanks for the explanation, that makes much sense.
When we have an update again, I'll try to see what will happen on the
Terminal Server.
BTW: on the current project, we update the application in the users night
(we are in Belgium, Terminal Server is in Malaysia for users in Singapore).
Regards,
Toni
TP wrote:
> Hi Tony,
>
> First, recognize that by breaking the locking contract you
> are asking for unpredicatable behavior by definition. In
> some cases you may be happy with the results, in other
> cases you may not.
>
> One difference between the workstations and the TS is
> that you are not opening multiple instances of the exe
> at the same time on each workstation.
>
> My guesspectation as to the behavior of the TS (in your
> scenario) would be at a minimum *all* instances of the exe
> would need to be terminated before the new app version
> would load. This makes sense because the exe is in the
> cache *once* and used by the different sessions.
>
> Did you verify via Task Manager that there were no
> instances of the exe still loaded in memory? A user could
> close the app properly but it still remain running with no
> visible window. If they logout the instance would terminate.
>
> Did you use Process Explorer to verify that there were
> no open file handles to the exe on the NAS (after all
> instances were terminated)?
>
> One thing I would suggest is to create unique shares for
> each TS user/session (I assume you are limiting each user
> to one session). Each TS user would run the exe from
> their unique share name instead of using the same share
> name as the other sessions.
>
> All of the shares would in reality point to the same folder
> with the same exe. The key difference is that windows
> would treat them as unique files. Keep in mind this will
> increase the memory use on the TS.
>
> Please let us know what you work out.
>
> Thanks.
>
> -TP
>
> Toni Van Remortel wrote:
>> Hi TP,
>>
>> Thanks for your explanation about the locking mechanism. I know this
>> method, and I'm aware of it's function.
>> We do go around the locking of the exe on Linux to make our lives
>> easier (just send a mail to the users telling them to restart the app
>> when they want to, to get the new version). It works perfectly in a
>> workstation environment.
>>
>> But that still doesn't explain why the old app is openend on the
>> Terminal Server if ALL TS users have closed it. It only disappears
>> when ALL TS users log out of TS (while workstation users don't need
>> to log out to get the new app, tehy only need to close it and reopen
>> it).
>> That is my concern. If nobody has the app open, why is the old app
>> still coming back?
>>
>> In my view, there is no difference between a single workstation and a
>> Terminal Server. If every TS users closes the app, it should resemble
>> the same situation as if the workstation user closes the app. I have
>> no clue why Terminal Server would keep the old app in memory, while a
>> workstation doesn't.
>>
>> Regards,
>> Toni
--
Regards,
Toni Van Remortel