From: Adam 

Paul Ranson wrote:

> I think you simply don't understand the elementary construct I'm talking
> about.
>
> In C++ I can write code that I can prove closes the connection, or returns
> it to the pool, on every path and in the presence of exceptions. It's simple
> and elegant at the user level. I don't understand why Java and C# don't have
> something similar, it would be compatible with existing syntax.
>

Yup but then one assumes you are opening & closing connections rather
than opening at the beginning & then maintaining connections. i.e. if
you have a class who's sole job is to handle connections & you are
going to use it from many different threads etc (e.g. in an appserver
handling many queries) then opening & shutting conns becomes expensive
& as such you want the class to persist in memeory & have the
required connection handling functionality such that a conn is opened &
then used as much as possible but the conn is never closed until shutdown.

You can do the same (wrt proving the closing of the conn) in java with the
conn.close() & in that case you simply use a template with all the conn
code already done & a bracketed statement where the method ends with
conn.close()

Adam


> Paul
>
> "Adam"  wrote in message
> news:428de53c$1{at}w3.nls.net...
>
>>Paul Ranson wrote:
>>
>>
>>>So your code has to check the connection before every call?
>>
>>Depends. No you don't have to. You can simply call to a pooled connection
>>& it will give you one from it's hashtable of conns when you need it.
>>
>>It's an architectural issue as you could simply use some form of ORM
>>instead (e.g. hibernate or JORM). If you want to get ambitious try:
>>
>>http://c-jdbc.objectweb.org/
>>
>>It is in C++ too given you have to write a class which instantiates the
>>conn & then closes/destructs it when the class has been finished with. Do
>>you keep that class around & if so how does it deal with
network/db errors
>>etc i.e. re-opening dead conns? Do you create the connection everytime &
>>in a multithreaded/multi-user env do you then run out of db handles?
>>
>>Gee it sounds to me like you'd need to arch the solution dependant upon
>>the use. Gosh that sounds similar....
>>
>>
>>>How does the pool determine that the connection is not active?
>>>
>>
>>All sorts of ways. An oft used method is to use a factory method to get a
>>conn & within the call to get the object from the factory you provide an
>>expiry time. There can be an upper limit config'ed into the pool by the
>>server admin i.e. you might set 10 minutes expiry but the server might go
>>"sod that mate you're getting 18K milliseconds tops".
>>
>>
>>
>>>Seems like  you're leaping through hoops to avoid doing it the easy way.
>>>
>>
>>Hardly. So are you keeping your object around & what happens if the db
>>refuses/network is down/slow etc.? Having to jump through hoops in
>>designing your class to guard against such occurences or simply create a
>>new connection every time you access the db?
>>
>>Gee seems to me that you should just get a pooling mech as that's the easy
>>way.
>>
>>
>>
>>>So why does Java not have destructors?
>>
>>You can (& should) close connections.
>>
>>
>>>Somebody must be able to say. I think it is because the original
>>>designers hadn't considered them in any other context than memory
>>>management. And now they're stuck...
>>>
>>
>>Hardly. No reason at all why you can't deference an object & then call
>>system.gc() or indeed for something like a dbconn you can call
>>conn.close().
>>
>>
>>Adam
>
>
>

--- BBBS/NT v4.01 Flag-5