Databases
StackOverflow2013
Postsdbo
POIn a system using EJB 3.1 and JPA 2.0, where should one cache CriteriaQuery objects?
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POIn a system using EJB 3.1 and JPA 2.0, where should one cache CriteriaQuery objects?
    primarykey
    data
    text
    <p>The JPA 2.0 specification mentions in section 6.9 that <code>CriteriaQuery</code> objects are serializable, and hence may outlive any open <code>EntityManager</code>s or <code>EntityManagerFactory</code> instances:</p> <blockquote> <p>CriteriaQuery objects must be serializable. A persistence vendor is required to support the subse- quent deserialization of a CriteriaQuery object into a separate JVM instance of that vendor’s runt- ime, where both runtime instances have access to any required vendor implementation classes.</p> </blockquote> <p>The EJB 3.1 specification says in section 21.2.2:</p> <blockquote> <p>An enterprise bean must not use thread synchronization primitives to synchronize execution of multiple instances, except if it is a Singleton session bean with bean-managed concurrency.</p> </blockquote> <p>If I have a stateless session bean that wishes to pre-build a bunch of <code>CriteriaQuery</code> objects using a <code>CriteriaBuilder</code> obtained from an injected <code>@PersistenceContext</code>, where should I stash the results?</p> <p>I can think of the following possibilities but am concerned that all but one run afoul of the "no synchronization primitives" clause above:</p> <ul> <li><p>In a <code>Map</code> that is stored as the value of one of my bean's instance fields, understanding that I'll have to synchronize access to the map. My take: section 21.2.2 violation.</p></li> <li><p>In a <code>ConcurrentMap</code> that is stored as the value of one of my bean's instance fields. My take: still a section 21.2.2 violation, as I'm sure the <code>ConcurrentMap</code> implementation synchronizes somewhere.</p></li> <li><p>In a <code>@Singleton</code> EJB's instance field somewhere, where the <code>@Singleton</code> exists only to serve as this kind of cache; with bean-managed concurrency this should be legal, but now all my stateless session beans that want to make use of this <code>CriteriaQuery</code> cache have to inject the singleton into themselves...seems like a lot of overhead.</p></li> </ul> <p>So it sounds like strictly speaking the last option is the only specification-compliant one. Am I correct?</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. This table or related slice is empty.
    1. USLaird Nelson
    plurals
    1. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload