Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 8 of 8 total
Thread DLL and Remote Session
Mon, Jan 27 2014 5:06 AMPermanent Link

Danie van Eeden

Hi,

I have a DLL that connects to a  DBISAM Server via Remote Session.
It seems that when this Session is "released" (FreeAndNil), the application calling the DLL hangs.

From a bit of debugging it seems the problem list with the Remote Pinging object / thread.

Is there anything I should be aware of when trying to use a DLL with  a remote session?

Other sessions being used are local sessions, and they seem ok.

DLL is loaded dynamically, but only once and then released after usage.

Many thanks in advance.
Mon, Jan 27 2014 12:51 PMPermanent Link

Raul

Team Elevate Team Elevate

On 1/27/2014 5:06 AM, Danie van Eeden wrote:
> I have a DLL that connects to a  DBISAM Server via Remote Session.
> It seems that when this Session is "released" (FreeAndNil), the application calling the DLL hangs.
>  From a bit of debugging it seems the problem list with the Remote Pinging object / thread.
> Is there anything I should be aware of when trying to use a DLL with  a remote session?
> Other sessions being used are local sessions, and they seem ok.
> DLL is loaded dynamically, but only once and then released after usage.
> Many thanks in advance.
>

While I don't use sessions in a DLL the hgnaing is not something i've
seen and we use DBISAM heavily otherwise.

I would suggest same rules should apply with DLL as with threads
(http://www.elevatesoft.com/manual?action=viewtopic&id=dbisam4&product=rsdelphiwin32&version=XE2&topic=Multi_Threaded_Applications):


basically unique session and unique database (i.e. do not use an
existing one from app nor default one).

With DLL the other aspect is to make sure you allocate and free any of
the components inside the dll (i.e. don't free the session from your
main code etc) and do it in the order (i.e. for closing close the
table/query then database and finally session).

Raul
Wed, Jan 29 2014 5:13 AMPermanent Link

Danie van Eeden

Hi and thanks for the reply.

1. The DLL is totally isolated from the calling application (host).
Its receives only Integer and PChar instructions. No objects are passed between the two.

2. The thread causing the issue isn't a thread I'm creating withing the DLL. Also the DLL isn't being called from a secondary thread. Simply from the Host Application's main thread. The thread causing the issue (or seemingly - I'm not pionting fingers Smile) is the RemotePing thread that checks the Session when doing Session.SetActive(False).

When the OSSetEvent is called (or sometimes the line just after) within dbisamen.pas the process hangs.

I get the feeling I'm doing something I shouldn't, but I have no idea where to start.

I stated in previous post - other Sesison seem ok, but they are all local sessions. Not remote.

Thx again
Any help appreciated
Wed, Jan 29 2014 8:47 AMPermanent Link

Matthew Jones

> The thread causing the issue (or seemingly - I'm not pionting
> fingers Smile) is the RemotePing thread that checks the Session when
> doing Session.SetActive(False).

I know nothing of this, but I'll suggest that the key will be to look at the source
code to see what creates this thread, and what causes it to close itself down. Then
you can call whatever it is that will close it and wait for it to stop before you
close the DLL functions. Threads in DLLs can work just fine, but you need to be
careful. You also need to make sure the global multithreaded variable is set, but
if you use a normal TThread as the base then that is automatic.

/Matthew Jones/
Wed, Jan 29 2014 7:26 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Danie,

<< I have a DLL that connects to a  DBISAM Server via Remote Session.
It seems that when this Session is "released" (FreeAndNil), the application
calling the DLL hangs.

From a bit of debugging it seems the problem list with the Remote Pinging
object / thread.

Is there anything I should be aware of when trying to use a DLL with  a
remote session? >>

Not, it's the exact same as when using it in an .exe.   Is the remote DBISAM
Database Server accessible when this occurs ?  It's possible that the
pinging thread may wait a bit on a response if the other end isn't "there".

Tim Young
Elevate Software
www.elevatesoft.com
Mon, Apr 14 2014 5:19 AMPermanent Link

Danie van Eeden

Hi,

just an update / perhaps a conclusion to this:

a) The Session was setup as remote session - even though the exe and server was running on the same machine.
b) The session was created with it's owner as one of my custom objects (created when required and freed in application finalization / dll finalization). When the custom object was freed on finalization, the session was also freed in the destructor.

The hang scenario (when calling StopPinging) was resolved by freeing the session earlier after final usage of the session - prior to the finalization of the dll.

No idea why this would make a difference.
Mon, Apr 14 2014 6:13 AMPermanent Link

Jose Eduardo Helminsky

HPro Informatica

Danie van Eeden

<<
a) The Session was setup as remote session - even though the exe and server was running on the same machine.
b) The session was created with it's owner as one of my custom objects (created when required and freed in application finalization / dll finalization). When the custom object was freed on finalization, the session was also freed in the destructor.
>>

If you are running the exe on the same machine you should not use remote session neither remoteping and the performance will increase if you access the data directly (without using netwok).

I have almost the same situation here, a service running on the same server machine that call a DLL and access a database avoiding netwok communications and the performance is fantastic and never see the problem with session because I am using local sessions and of course there is no need of using remoteping.

Eduardo
Mon, Apr 28 2014 10:57 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Danie,

<< just an update / perhaps a conclusion to this:

a) The Session was setup as remote session - even though the exe and server
was running on the same machine.
b) The session was created with it's owner as one of my custom objects
(created when required and freed in application finalization / dll
finalization). When the custom object was freed on finalization, the session
was also freed in the destructor.

The hang scenario (when calling StopPinging) was resolved by freeing the
session earlier after final usage of the session - prior to the finalization
of the dll. >>

I'd have to trace it through to say for sure, but the most likely cause is
an issue with the finalization order as it relates to the destruction order
of the object instances.

Tim Young
Elevate Software
www.elevatesoft.com



Image