From: "Paul Ranson" 

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.

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