tags:

views:

34

answers:

2

I have two grails (1.2.1) applications deployed in two different app servers. One app contains the main site (view, controller, domain, etc.) and the other app has a Quartz plugin that performs the core and backend processing. Both app is sharing the Domain classes and same DataSource config. This means that the two app is accessing same database and tables.

My question is: are there any penalty on querying the database?

I'm just noticing some slowness on the main site app if the Quartz job app is running. No clear proof or stats though. Can the hibernate component on each app able to handle concurrency and transactions properly in the some event? Or do I need to configure something in grails-app/conf on each app too? right now, I didn't add extra configuration though.

Thanks.

+2  A: 

The main problem I could think of would be issues with 2nd level caching. If both apps try and cache data it can cause StaleObjectExceptions and similar when the caches get out of sync with the DB due to it being changed by the other app. 2nd level caching is disabled by default though so you might not have an issue there.

It also depends on whether you are using the optimistic locking provided by default or explicit locks with the lock() method on your domain classes. Optimistic locking should not cause a slow down (but could cause exceptions on save if the other app has updated the row).

leebutts
thanks for the information. i think the 2nd level caching is enabled in 1.2.1, and yes, i'm seeing org.hibernate.StaleObjectStateException in logs. so do i need to turn off that flag? what would be the downside if that's the case? sorry, still not familiar in the internal of grails framework.
firnnauriel
You can either turn it off completely in DataSource.groovy or you can add code to your application to handle an exception on save and do a refresh(), update it again and retry the save. You have explicitly enable caching on each class though so you may not actually be using the cache (even if it is enabled).
leebutts
The stale object exceptions will be from the optimistic locking (done via the version column on the domain classes).You can turn this off by adding "version false" to the mapping closure on each domain class. The risk is that you may lose updates with each system overwriting each other. You need to decide whether the risk is small enough to avoid the extra work of handling StaleObjectExceptions.
leebutts
so the StaleObjectStateException is not due to 2nd level caching? yes, I have some domains that has no 'version' fields and there are some domains that i didn't modify. i haven't tried disabling the 2nd level cache, and it seems i had to change several code if i do that? but do you think disabling 2nd level cache will improve the performance?
firnnauriel
if you haven't added 'cache true' to any of your domain classes then nothing will be getting cached, even if the 2nd level cache is enabled. So it won't make any difference to disable it (I don't think).I would check the domain classes that still have version fields, it is likely they are causing the exceptions
leebutts
A: 

Have you considered an architecture where one application masters your domain classes and the other integrates with that through messages or web services calls? In so doing, you might avoid some of the problems associated with the duplication across your applications.

Chris Alef