FreeTDS Development Group

["ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>]

> 
> > Once a query is sent to the server, the line is absolutely 
> quiet until the
> > server answers (if ever).  There is no interim message or 
> heartbeat of any
> > kind.  
> > 
> > I don't understand why the stack would close the connection 
> merely because
> > it's idle.  A telnet session can stay up indefinitely without anyone
> > typing anything.  
> 
> Well, there have to be TCP keep-alives but this will happen 
> transparent
> to the application, etc.
> 
> Let's assume for now that based on this information about how 
> the protocol 
> works, a seperate network timeout is not required.
> 
> In this case, select needs to be populated with query_timeout. Do you
> want me to update the patch or do you want to do that Frediano?
>  

I posted patch from CVS but I think it's easier for me to provide an
updated patch.

> > ISTM that a big lock in db-lib is OK.  The db-lib 
> "threading" model, if we
> > can call it that, is that threads may not share a dbproc.  Mutual
> > exclusion, then, is required only when inter-process lists 
> are maintained
> > (e.g.connection_list, as you mentioned).  I haven't been 
> able to look at
> > your code yet, but do I understand correctly from your 
> postings that we
> > agree?  
> 
> Yes, I think we agree. I don't like the big lock model 
> either, but until
> I (or someone else) does a partial re-write of dblib, I think 
> it's the 
> best solution.
> 

I committed a week ago (or more) code for mutual exclusion of connection
list.

> 
> > Are you using current CVS? Do you call dbexit while other thread are
> > processing data? Try to remove dbexit call with current 
> CVS. Where does
> 
> Of course not! That would most certainly result in a 
> disaster. The version 
> of FreeTDS I use currently is a heavily patched 0.63.
> 

It's hard to discuss the same changes from two different trunks. Can you
post your patch. Why does 0.63 need a so heavy patch?
I think that dbexit can be update even to be called from multi-thread.
This at this library problem:
- library A use dblib
- library B use dblib
Both library
- dbinit
- connect
- select
- get reply
- close connection
- dbexit
Now program C use both library but it do not know that A and B use
dblib. Now it can happen that
- A call dbinit
- B call dbinit
- B connect
- A connect, select and close
- A call dbexit (that free all connection)
- B try to select... crash...
Not so fine. A solution is to count dbinit calls and decrement in dbexit
so when A call dbexit nothing happen.
This is why I also proposed a counter for context.

> >From memory, I saw crashes and corruption mostly during things like 
> closing and opening dblib connections while other threads process
> queries on other untouched dblib connections. Obviously, each 
> connection
> is protected by an application mutex. The underlying dblib routines
> modify connection_list and this will not work well with other threads
> access it without mutual exclusion.
> 
> I don't think it's necessary to discuss this matter any further. I
> think we all agree that we need mutual exclusion and thread 
> safety measures
> of one form of another in dblib. Let's concentrate on the solution.
> 

Your patch has been partially committed to CVS. I'll try to reproduce
your problem.

> > your application hang inside dblib? I think that a solution 
> is to use a
> > reference counter for tds_ctx. Increment while creating TDSSOCKET or
> > dbinit and decrement while destroying TDSSOCKET or dbexit.
> 
> I disagree, I would say the right solution is a tds_ctx per DBPROCESS.
> That way, almost all the thread safety and mutual exclusion problems 
> go away.
> 

I agree this is a correct solution. I'll try to reproduce your problem.

freddy77