views:

263

answers:

2

I'm using JPA and I am using second-level cache for all the reference entities. Everything's working well, I can get the entities from second-level cache is they were already been selected before.

Now, I have two applications, they both use the same database (so they both use the same table, values, etc). 1.The read-only application just read data from database, it doesn't modify the database at all. Therefore, I choose the "READ_ ONLY" concurrency strategy for the second-level cache, aiming at a better performance. 2.The read-write application read and write as well the data of database, it modify the database. Consequently, I have to choose the "READ_ WRITE" or "NONSTRICT_ READ_ WRITE" concurrency strategy for the second-level cache.

However, the concurrency strategy is assigned in the annotation of each entity class, so I cannot change it programatically. (I don't use class mapping files for JPA, so I can't use two mapping files, each for a different concurrency strategy for the same entity class.)

My Question is, is there a good way to change the concurrenty strategy of the second-level cache on the fly according to my 2 different applications?

+2  A: 

I have not used Hibernate, but at least if you use JPA it is possible to override even a single annotation with a deployment descriptor file. You should also be able to override also any vendor specific property with the deployment descriptor.

Unfortunately I cannot give you an example but hope this helps you.

tputkonen
Why the -1?? You can get more information from JPA specification or EJB3 in action. My answer should help you forward.
tputkonen
Hello, tputKonen! Your response really gives me a clue. I'll do some googling on "how to override annotation with deployment descriptor file". Thanks! The -1 is not made by me... and it's my first time using this website, so I don't have enough reputation score to make it up... I'm sorry for that. I'll come back to you soon when I got something.
keweishang
Hello, tputKonen! By deployment descriptor file, do you mean orm.xml? and in orm.xml, could I add things not belong to the JPA specification, like the equivalence of "@org.hibernate.annotations.Cache(usage = org.hibernate.annotations.CacheConcurrencyStrategy.READ_WRITE)", which is a hibernate thing.
keweishang
Please check out persistence.xml and element called properties. Please let me know if you need more help, at the moment I don't have the time to check it our more, but I'll look this more later if you need help.Please also download EJB3 persistence specification.
tputkonen
Thank you, tputKonen!I have just had a look at the EJB3 persistence specification, and I guess the JPA XML descriptor file (orm.xml) is the "deployment descriptor file" as you mentioned.I think there are two types of XML metadata files. One is Hibernate mapping file, another is JPA XML descriptors (orm.xml).I think the Hibernate vendor specific annotations(mappings as well) is not supported by JPA XML descriptors. On the other hand, you can’t override annotations with Hibernate XML mapping files; you have to define a complete entity class mapping in XML.
keweishang
So I guess I can't override just part of the annotations of one entity, but rather replace all the annotations of one entity with Hibernate mapping file? is that correct?
keweishang
In the <Java Persistance with Hibernate> Book, it is also said that:"You also need to consider vendor extensions when you make a decision for an XML metadata format. The Hibernate XML format supports all possible Hibernate mappings, so if something can’t be mapped in JPA/Hibernate annotations, it can be mapped with native Hibernate XML files. The same isn’t true with JPA XML descriptors—they only provide convenient externalized metadata that covers the specification."
keweishang
In the <Java Persistance with Hibernate> Book. It is said that "On the other hand, you can’t override annotations with Hibernate XML mapping files; you have to define a complete entity class mapping in XML."
keweishang
A: 

So Therefore, I think the current solution is to replace all the annotations of each entities with Hibernate mapping files, so that for different deployment (application as well), we could use different Hibernate mapping files.

keweishang