[TonyHH]

Thanks for that! All worked fine but would like to see the tutorial updated as I had the same problem you guys had. But overall I think MyEclipse has pretty good support!

[TonyHH]

Just a question why does the DAO have to implement an interface when the interface can do absolutely nothing?!!?

[mcintosh_i]

Yep I can confirm that the interface is not needed, it still works without it.

Thanks Paras, great example, very helpful.

One question: the userDAOService bean is basically just a transaction wrapper, so is there any way that we can make this more generic, i.e. by not having to hard-wire the target to that particular “persistenceLayer” bean? (that bean is basically a userPersistenceLayer really). If we didn’t have to hard-wire the reference to persistenceLayer in the transaction bean, we could use the transaction bean for ANY objects we wanted.

In other words, instead of having the line:
<property name=”target”><ref local=”persistenceLayer”/></property>
…
can we pass this reference in our client code? Otherwise we’ll need one transaction bean for every object we might potentially want to save.

cheers,
Ian

[mcintosh_i]

To answer my own question, the API doc for TransactionProxyFactoryBean gave me the answer. (I’m new to spring so didn’t realise you could declare abstraction in the xml bean def file). Here’s their example:

<bean id=”baseTransactionProxy” class=”org.springframework.transaction.interceptor.TransactionProxyFactoryBean”
abstract=”true”>
<property name=”transactionManager” ref=”transactionManager”/>
<property name=”transactionAttributes”>
<props>
<prop key=”insert*”>PROPAGATION_REQUIRED</prop>
<prop key=”update*”>PROPAGATION_REQUIRED</prop>
<prop key=”*”>PROPAGATION_REQUIRED,readOnly</prop>
</props>
</property>
</bean>

<bean id=”myProxy” parent=”baseTransactionProxy”>
<property name=”target” ref=”myTarget”/>
</bean>

<bean id=”yourProxy” parent=”baseTransactionProxy”>
<property name=”target” ref=”yourTarget”/>
</bean>

[simpigill]

I used the information from this thread and build my application. Now DBA is complaining that I am eating up number of sessions (or processes) allowed.

Ques: Do I need to make changes to all my beans as suggested for UserDAO? ie. create XXXDAOservice for each one of them?

[TonyHH]

I have the same problem as simpigill. Using this example I’ve created a tracker application to track web user etc. However, it seems I’m starting to get com.mysql.jdbc.exceptions.MySQLNonTransientConnectionException too many connections. Anyone know how we should be handling connections?

[TonyHH]

Funnily enough I looked around on google and found that simpigill had posted the question onto a few other sites and it looked like he figured out the solution himself. Given we’re using the same design I thought I’d try his solution out with using C3P0 for JDBC connection management.

At first I couldn’t get it working. But after awhile of searching on google I found that you must set minpoolsize to zero. I set my max connections on MySQL to 10 for testing purposes. So I’m using the settings below. But the most important thing is setting min_size to zero.

<code>
<property name=”c3p0.max_size”>6</property>
<property name=”c3p0.min_size”>0</property>
<property name=”c3p0.timeout”>30</property>
<property name=”c3p0.max_statements”>5</property>
<property name=”c3p0.acquire_increment”>1</property>
<property name=”connection.provider_class”>org.hibernate.connection.C3P0ConnectionProvider</property>
</code>

simpigill also seem to stumbled on this solution as I can see his postings on another forum. The place I found the solution said that setting it to zero isn’t a good thing and he didn’t explain why. Anyone know of an explanation as to why this works and why it’s not a good idea to set the min pool size to zero?

[TonyHH]

Okay I figured out why minpoolsize makes this work.

Minpoolsize (or min_size) is the setting to tell c3p0 that’s the minimum amount of connections c3p0 needs to manage in the pool. However, if this is set to zero then c3p0 doesn’t maintain any connections in the pool thus the connections timeout and get released (so we don’t run out of database connections). However, this is a bad way of implementing things as each time a new transaction is started we need to connect to the database which can be expensive especially in larger apps.

This makes me think that the sessions are not being handled properly? As in they aren’t being closed off or that when new sessions and open connections are being opened but not reused. Anyone with opinions on this matter?

[TonyHH]

Alright since nobody knows what’s going wrong here I found the answer to my problem and probably simpigill’s problem too. For me it was a stupid silly problem but probably very easily made. I was instantiating the Spring BeanFactory inside my doPost and doGet methods of my servlets which should be really be done in the init() method. Now of course everytime these methods are use we will get a new BeanFactory created thus a new connection (pool) to the database. The actual creation of the beans by the bean factory and the accessing of these beans causes Hibernate to create a connection. If you have a third party connection pooling manager like c3p0, it will create a connection pool accordingly to the parameters you’ve set for c3p0. So when you instantiate the BeanFactory and create a set of beans (and access them) you also create a connection pool. Having multiple BeanFactories gives you multiple connection pools so it’s important that you don’t instantiate multiple BeanFactories unless that’s what you really want to do.

So if you are working on a webapp and exceeding max db connections best to check out your servlet code and no don’t set min_size in c3p0 to zero because this defeats the purpose of connection pooling.

Hope that helps someone out.

[Author]

Posts