Re: [v.1.1.3 September 28 2005] Global exception.

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Wed Nov 30 2005 - 04:25:15 EST

  • Next message: noban: "Re: Cayenne modeler doesn`t reengeneer DB schema"

    Hi Claudio,

    Good to know that you found the cause of the problem.

    Of course extra docs about closing the connection wouldn't hurt.
    Still IMO this would be redundant - it is implied that if the user
    code gets a connection from a DataSource, it is the responsibility of
    this user code to close such connection. I am not aware of any
    exceptions from this rule of thumb. In other words if you are doing
    work at the DataSource/Connection level, you are out of the realm of
    Cayenne and a normal JDBC approach applies.

    Regarding providing direct access to connection from DataContext - I
    am against this, as this breaks the abstraction. The way you are
    doing it is quite appropriate for a specific application, however
    generally DataContext itself shouldn't make any assumptions about the
    underlying stack.

    Andrus

    On Nov 30, 2005, at 11:48 AM, Claudio Rosati wrote:
    > Hello Andrus,
    >
    > I've following your suggestions but every thing was OK. So I've
    > started
    > debugging my application with Cayenne sources to better understand the
    > executed operation, in order to identify the problem.
    >
    > After a day I've discovered the previously submitted code was not the
    > problem's cause, but just an effect of another code executed just
    > before it:
    >
    >
    > public static long getNextRecordCode ( )
    > {
    >
    > long code = -1;
    > PreparedStatement ps = null;
    > ResultSet rs = null;
    >
    > try {
    >
    > DataContext dc = CayenneUtility.createDataContext();
    > Connection con = dc.lookupDataNode(
    >
    > dc.getEntityResolver().lookupDbEntity(Record.class).getDataMap()
    > ).getDataSource().getConnection();
    >
    > ps = con.prepareStatement("SELECT nextval('code_provider')");
    > rs = ps.executeQuery();
    >
    > if ( rs.next() )
    > code = rs.getLong(1);
    >
    > }
    > catch ( Exception ex ) {
    > ...
    > }
    > finally {
    > try {
    > if ( rs != null )
    > rs.close();
    > }
    > catch ( Exception ex ) { ... }
    > try {
    > if ( ps != null )
    > ps.close();
    > }
    > catch ( Exception ex ) { ... }
    > }
    >
    > return code;
    >
    > }
    >
    >
    > As you can see, I've not closed the JDBC connection thinking that
    > this could
    > cause problems to Cayenne. Instead, after debugging through Cayenne
    > code,
    > I've discovered that the returned connection is a
    > PooledConnectionImpl whose
    > close() doesn't really close the JDBC connection, but release the
    > connection
    > to the pool instead.
    >
    > So, closing the connection solved the problem.
    >
    > Now I would like to suggest the following:
    >
    > 1. add notice in the PoolManager.getConnection methods
    > documentation about the need to call close() in order
    > to release to connection to the pool;
    >
    > 2. same for PooledConnectionImpl documentation;
    >
    > 3. add the following method in DataContext (or at least
    > a corresponding documentation) in order to easily
    > obtain a JDBC connection from Cayenne
    >
    > public Connection getConnection ( Class target )
    > throws ...
    > {
    > return lookupDataNode(
    > getEntityResolver().lookupDbEntity(target).getDataMap()
    > ).getDataSource().getConnection();
    > )
    >
    > for the rare situations where handling directly
    > with JDBC is more convenient (or, maybe, the only
    > solution) than using Cayenne (e.g. "SELECT count(*) FROM ...").
    >
    >
    > Claudio
    >
    >
    > ------------------------------------
    > Advanced Computer Systems S.p.A.
    > Claudio Rosati
    > Project Manager
    > claudio.rosat..csys.it
    > via Della Bufalotta 378
    > 00139 Roma, RM
    > Italy
    > tel: +39 06 8709 0516
    > fax: +39 06 8720 1502
    > ------------------------------------



    This archive was generated by hypermail 2.0.0 : Wed Nov 30 2005 - 04:25:19 EST