Is it possible (and does it make sense) to use the JDO Level 2 Cache for the Google App Engine Datastore?
First of all, why is there no documentation about this on Google's pages? Are there some problems with it? Do we need to set up limits to protect our memcache quota?
According to DataNucleus on Stackoverflow, you can set the following persistence properties:
datanucleus.cache.level2.type=javax.cache
datanucleus.cache.level2.cacheName={cache name}
Is that all? Can we choose any cache name?
Other sources on the Internet report using different settings.
Also, it seems we need to download the DataNucleus Cache support plugin. Which version would be appropriate? And do we just place it in WEB-INF/lib or does it need more setup to activate it?
Before you can figure this out, you have to answer one question:
Which version of DataNucleus are you using?
Everything on this post has to do with the old version of the plugin -- v1. Only recently has the Google Plugin for Eclipse supported v2 of the DataNucleus plugin for AppEngine (which is basically the conduit between AppEngine and the DataNucleus Core).
I'd recommend upgrading to v2 of the Datanucleus plugin for AppEngine -- if you're using Eclipse, it's easy -- there's a UI for it that allows you to select v1 or v2. Just go to your Project properties and find the App Engine settings and look for "Datanucleus JDO/JPA version".
Plus, you have to make a change to your jdo-config.xml. Specifically, you have to change just one property:
<property name="javax.jdo.PersistenceManagerFactoryClass" value="org.datanucleus.api.jdo.JDOPersistenceManagerFactory"/>
SO -- Once you've upgraded to v2, this is how you specify caching (an addition to jdoconfig.xml):
<property name="datanucleus.cache.level2.type" value="jcache"/>
<property name="datanucleus.cache.level2.cacheName" value="NameItWhateverYouWant"/>
At this point, caching should happen automatically every time you put and get using a PersistenceManager. Hooray!
No known problems with anything to do with L2 caching and GAE/J. If people have problems then perhaps they ought to report them to Google. Set the cache name to what you wish. Anything put into memcache has to be Serializable, obviously, since that is what memcache does. Yes, you need the datanucleus-cache plugin (ver 1.x), and put it in the same place as any other DN jars. One day Google will update to use DN 2.x
It seems to have problems instead: I tried (with JPA) and I got the error someone else already reported: http://code.google.com/p/datanucleus-appengine/issues/detail?id=163
Related
I am moving my project to spring boot 2.3.5 which has driver 4.6 and LatencyAwarePolicy looks like disappeared from existence. I wonder do we have similar policy builder for driver 4.6 or what is the best approach for 4.6.
https://docs.datastax.com/en/drivers/java/3.6/com/datastax/driver/core/policies/LatencyAwarePolicy.Builder.html
I search but could not find anything in the docs. maybe https://github.com/datastax/java-driver/blob/4.x/core/src/main/java/com/datastax/oss/driver/internal/core/loadbalancing/BasicLoadBalancingPolicy.java
with BasicLoadBalancingPolicy I can connect without data center name but I am confused is this as good as LatencyAwarePolicy ?
The default load balancing policy in 4.x now has best practices baked in, including token awareness and busy node avoidance (which was the goal of LatencyAware).
This blog post discusses more:
https://www.datastax.com/blog/improved-client-request-routing-apache-cassandratm
You can still implement any LBP you care to by implementing the LoadBalancingPolicy interface, but it normally should not be necessary.
I have a spring application on heroku (seems like there is no way to use ehCache there). I found several projects on github like hibernate-memcached for the second level cache, but they have just few stars on github and I'm not sure if they are not buggy.
Would you recommend anything for java + hibernate 4 second level cache based on memcached?
https://github.com/kwon37xi/hibernate4-memcached
I made this.
One of heroku user sent me an email that he was using this library.
I have never been used heroku, but anyway I think this library work fine with heroku.
I heard heruku memcached requires authentication, refer to this wiki page https://github.com/kwon37xi/hibernate4-memcached/wiki/SpyMemcachedAdapter about authentication.
We've been working with Grails for a while and my Team Lead raised some questions about the Grails ORM (GORM):
How do we maintain the database schema once we have moved to production?
Can we update the database schema with Grails?
If the schema is updated, will the changes be automatically reflected / does the framework take care of this?
Is there any plugin for Grails that will allow us to update the schema without headaches?
I recently released the official Grails plugin for database migrations - see http://grails.org/plugin/database-migration and the docs at http://grails-plugins.github.com/grails-database-migration/docs/manual/index.html
I'm working with the author of Liquibase on this, so the older liquibase plugin is now deprecated and the new one should be used since it uses the latest version of Liquibase (2.0) and is officially supported by SpringSource. See http://blog.liquibase.org/2011/01/new-standard-liquibase-plugin-grails-database-migration.html for his announcement.
Ask usage questions on the Grails User mailing list (signup from http://grails.org/Mailing+lists) or the new plugin forum at http://grails-plugins.847840.n3.nabble.com/ or email the author directly :)
Remove dbCreate parameter in DataSource.groovy for your production environment - this will stop GORM from auto-updating DB schema.
Sure. Use LiquiBase plugin.
GORM can do it with dbCreate='update', but it's strongly not recommended. For instance, if you rename a field, GORM/LiquiBase can never determine that you have to migrate the data, and not just drop+create.
In one line: grails db-diff to generate LiquiBase's changelog.xml, and grails migrate -Dgrails.env=<whatever environment> to apply it to respective db server.
While the "auto create" functionality is ok to get a project up and running I find liquibase the best way to keep the db up-to-date. There is a grails plugin and I believe work is under way on a DSL too.
So, create a baseline schema (you could use liquibase's generate-changelog) then make all future changes through liquibase and it will manage the updates, rollbacks and even some db interop for you. You can set your DataSource.groovy config to verify and grails will not start up if the schema does not match the domain config:
environments {
development {
dataSource {
dbCreate = "validate"
You may also be interested in the liquibase-runner plugin to run your migrations on application start.
I am trying to configure hibernate search for my application by reading several web tutorials, the majority uses annotation but I uses xml mapping, also, many tutorial are saying to use spring and maven while I don't uses these.
Can someone help and provide some starting point for configuring hibernate search, many web tutorial are not working for me
The application is a gwt application using gilead with hibernate on the back end
As pointed out in the previous answer, Hibernate Search does not have a xml configuration. You can configure Hibernate via xml, but not Search. Since Hibernate Search 3.3 there is an alternative, however, which is the programmatic configuration api - http://docs.jboss.org/hibernate/stable/search/reference/en-US/html_single/#hsearch-mapping-programmaticapi
There is an object called SearchMapping. Once instantiated it offers an fluent API to configure Search the same way you would do with annotations. Add the configured SearchMapping instance to your Hibernate Configuration instance using the key *hibernate.search.model_mapping* and Search will automatically bootstrap together with Hibernate Core. There is not much to it. You don't need Spring.
Once Search is running you probably want to write a few lines of code to index your existing database. There is code for that in the online manual.
Last, but not least you need some searches. Have a look how to create a FulltextQuery. Your system probably gets some sort of search input in what for so ever. Your task is to transform the search input from the "frontend" into a Lucene query which you can then pass to Search in order to execute the search and return managed objects.
Last, but not least - maven is a completely different thing. Now we are talking build systems. Using maven you can get automatically download the artifacts from the JBoss Maven repository. However, there are also dist bundles on SourceForge is this is more what you are after. Check http://www.hibernate.org/subprojects/search/download for Search download information.
Hope this helps.
http://docs.jboss.org/hibernate/search/3.3/reference/en-US/html_single/#d0e43
Hibernate Search, however, has itself its own set of annotations (#Indexed, #DocumentId, #Field,...) for which there exists so far no alternative configuration.
I also remember seeing something like this in "Hibernate Search in Action", where the author said that there's not much demand for non-annotation configuration (I don't have my copy now, so, I may be wrong). I guess that there is still not enough demand.
Note that Hibernate itself can be configured via XML, and I assume that you can mix both (XML for Hibernate mappings, annotations for Hibernate Search mappings).
We are looking at implementing a caching framework for our application to help improve the overall performance of our site.
We are running on Websphere 6.1, Spring, Hibernate and Oracle. The focus currently is on the static data or data that changes very little through out the day but is used a lot.
So any info would be great. I have started my google search and reading but wanted to get a feel for what has worked for members of the community. One of the things that we are interested in is the ability to have the system invalidate the cache when a change does happen in the underlining data.
Thanks
Update:
I came across an article on the IBM web site where it says that Hibernate's Cluster aware caches in conjunction with WebSphere Application Server has not been determined yet; therefore, is is not yet determined whether or not their use is supported.
Thoughts on that? We are running in a clustered environment.
Well the hibernate cache system does just that, I used ehCache effectively and easily with Hibernate (and the second level cache system).
Lucene could be an option too depending on the situation. Hibernate Search or Compass could help with that (although it might take some major work).
Replication using Terracotta could also be an option although I've never done it.
Hibernate has first and second level caching built in. You can configure it to use EhCache, OSCache, SwarmCache, or C3P0 - your choice.
You can also leverage WebSphere's default cache i.e. DynaCache to implement the second level cache. This will allow you to administer, monitor and configure your cache leveraging WebSphere caching infrastructure
I've used ehCache and OSCache and found OSCache to be easier to configure and use.
One of the things that we are
interested in is the ability to have
the system invalidate the cache when a
change does happen in the underlining
data.
From what I can see, Hibernate doesn't actually do the above - from Hibernate's docs:
Be careful. Caches are never aware of
changes made to the persistent store
by another application (though they
may be configured to regularly expire
cached data).
Obviously what it means is that a cache doesn't have ESP, and can't tell if an app not in the cluster has called straight DML on the database - but I am guessing that what you want is an ability to expose a service for legacy apps to hook in and invalidate the cache when they do update that data. And there isn't, to my knowledge, a suggestion about how this might be done.