One more question. How does iBatis know when to close the connections with the SIMPLE data source? I thought it was when the DaoManager when out of scope. Currently, our Controller classes (where that code is from) use all static methods. If my assumption about scope is correct, then we will need to switch to new instances of each Controller with non-static methods to implement your suggestion, correct?
-----Original Message-----
Question:
which DataSource (i.e. connection pool) are you using? On 9/30/05, Mitchell, Steven C <[EMAIL PROTECTED]> wrote: I've used iBatis on many projects now. My latest project has run out of Oracle connections a couple of time during testing, which has me concerned. There did not appear to be any kind of looping going on. I found only one Controller method that called multiple methods that used the same DAO. I changed the parent method to get the DAO and pass it into the two child methods.
Now, I'm wondering if I am using Transactions as they were indented. I've only used Transaction on updates. Should I use them on reads to make sure everything gets cleaned up. Here is an example of what I do:
// NO TRANSACTION FOR QUERIES
public static Company getCompany( Integer companyId ) throws IVRPasswordException { try { final DaoManager daoManager = DaoHelper.getDaoManager(); final CompanyDao companyDao = ( CompanyDao ) daoManager.getDao( CompanyDao.class ); return companyDao.getCompany( companyId ); } catch ( Exception e ) { throw new IVRPasswordException( e ); } }
// TRANSACTION FOR ALL UPDATES/INSERTS/DELTES
public static void updateCompany( Company company ) throws IVRPasswordException { DaoManager daoManager = null; try { daoManager = DaoHelper.getDaoManager(); daoManager.startTransaction(); final CompanyDao companyDao = (CompanyDao) daoManager.getDao( CompanyDao.class ); companyDao.updateCompany( company ); daoManager.commitTransaction(); } catch ( Exception e ) { throw new IVRPasswordException( e ); } finally { if ( daoManager != null ) { daoManager.endTransaction(); } } }
Thoughts?
Steve
Mitchell
|
- Re: Transaction Best Practices Clinton Begin
- RE: Transaction Best Practices Mitchell, Steven C
- RE: Transaction Best Practices Mitchell, Steven C
- Re: Transaction Best Practices Clinton Begin