[JBoss JIRA] (JGRP-2300) DNS_PING in AWS ECS cannot cluster with dynamic port mappings
by Eric Thompson (Jira)
[ https://issues.jboss.org/browse/JGRP-2300?page=com.atlassian.jira.plugin.... ]
Eric Thompson commented on JGRP-2300:
-------------------------------------
Hello [~sebastian.laskawiec]! In the dynamic port mapping example this is a typical DNS entry:
{code}
$ dig jgroups.dev.auth.example.com.svc.cluster.local SRV
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.68.rc1.58.amzn1 <<>> jgroups.dev.auth.example.com.svc.cluster.local SRV
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16690
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;jgroups.dev.auth.example.com.svc.cluster.local. IN SRV
;; ANSWER SECTION:
jgroups.dev.auth.example.com.svc.cluster.local. 10 IN SRV 1 1 32921 9ec82e3f-3a0e-4e30-b785-17879c63cd7d.jgroups.dev.auth.example.com.svc.cluster.local.
jgroups.dev.auth.example.com.svc.cluster.local. 10 IN SRV 1 1 32923 60b5a820-9678-4bd2-84c6-00061a52bde0.jgroups.dev.auth.example.com.svc.cluster.local.
jgroups.dev.auth.example.com.svc.cluster.local. 10 IN SRV 1 1 32915 9d9d78d0-8919-4b91-9df8-2e4e65afedae.jgroups.dev.auth.example.com.svc.cluster.local.
jgroups.dev.auth.example.com.svc.cluster.local. 10 IN SRV 1 1 32917 161f3d66-f1e3-46f4-a44f-ebda925a25c6.jgroups.dev.auth.example.com.svc.cluster.local.
;; Query time: 2 msec
;; SERVER: 10.42.3.2#53(10.42.3.2)
;; WHEN: Fri Sep 21 01:45:44 2018
;; MSG SIZE rcvd: 481
{code}
You can see ports of 32921, 32923, 32915, and 32917. But the containerized JVM is unaware of this mapping and will refer to itself as <external_ip>:7600 when making a service discovery request. This is a new address and so the receiving node adds it to the discovered_hosts variable.
Anyway, it fails to work and results in endless redirects in the front-end and no way to load the realm login page.
> DNS_PING in AWS ECS cannot cluster with dynamic port mappings
> -------------------------------------------------------------
>
> Key: JGRP-2300
> URL: https://issues.jboss.org/browse/JGRP-2300
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.16
> Environment: AWS ECS Cluster with DNS based service discovery using jboss/keycloak:latest containers
> Reporter: Eric Thompson
> Assignee: Sebastian Łaskawiec
> Priority: Critical
> Fix For: 4.0.16
>
>
> When running an ECS cluster with jboss/keycloak:latest containers dynamic port mapping of all ports is required to allow more than one container to run per EC2 instance. Using SRV based service discovery records will allow each node to find the rest of the nodes, but when a discovery request is sent the receiving node sees the sender as IP:7600 instead of the dynamic port. It then sees this as a "new" node and tries to send discovery requests to it. And somehow it is also getting node IDs and trying to send requests to those!
> See the following log, there are only 4 actual nodes and the each have a different 5 digit port number:
> {code}
> ### Service discovery with dynamic port mapping
> 2018-10-10 20:17:44,178 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) Performing discovery of the following hosts [10.42.3.44:7600, 10.42.3.56:32949, 10.42.3.56:32951, 10.42.3.44:32954, c5b479b7b6d5, 10.42.3.44:32952, 10.42.3.56:7600, 17081c624290, 63976b7fae70, 557cbd7891a2]
> 2018-10-10 20:17:44,178 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 10.42.3.44:7600
> 2018-10-10 20:17:44,179 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 10.42.3.56:32949
> 2018-10-10 20:17:44,179 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 10.42.3.56:32951
> 2018-10-10 20:17:44,180 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 10.42.3.44:32954
> 2018-10-10 20:17:44,181 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to c5b479b7b6d5
> 2018-10-10 20:17:44,181 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 10.42.3.44:32952
> 2018-10-10 20:17:44,181 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 10.42.3.56:7600
> 2018-10-10 20:17:44,182 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 17081c624290, IP: 10.42.3.56:7600
> 2018-10-10 20:17:44,182 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 17081c624290
> 2018-10-10 20:17:44,182 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-238,ejb,17081c624290) Received discovery from: 17081c624290, IP: 10.42.3.56:7600
> 2018-10-10 20:17:44,182 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 63976b7fae70
> 2018-10-10 20:17:44,183 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-240,ejb,17081c624290) 17081c624290: sending discovery request to 557cbd7891a2
> 2018-10-10 20:17:44,187 WARN [org.jgroups.protocols.TCP] (TQ-Bundler-7,ejb,17081c624290) JGRP000032: 17081c624290: no physical address for c5b479b7b6d5, dropping message
> {code}
> This code seems to be part of the problem in this case: https://github.com/belaban/JGroups/blob/87d15ec848aa3d482ae792ef152f7e36e...
> See that code uses the incoming address and adds it to the discocvered_hosts, but those addresses are ALWAYS inaccurate in this case.
> Because this is what the recipient of the service discovery request sees (ie: all the ports are the default 7600):
> {code}
> 2018-10-10 20:35:15,229 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:15,231 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:15,232 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-397,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:15,233 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:17,234 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:17,236 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:17,238 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-397,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:17,238 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:19,239 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:19,240 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:19,242 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:19,243 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:21,246 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:21,247 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:21,253 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:21,253 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:23,247 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:23,249 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:23,251 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:23,251 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-350,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:25,252 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:25,253 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:25,255 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> 2018-10-10 20:35:25,256 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-237,ejb,17081c624290) Received discovery from: 63976b7fae70, IP: 10.42.3.44:7600
> {code}
> In this state the cluster never seems to work properly and the Keycloak interface breaks in many frustrating ways.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
- 1
- 0
[JBoss JIRA] (WFLY-11234) Since WildFly 14 i18n ResourceBundle properties file not found if without locale
by Anton Pussep (Jira)
Anton Pussep created WFLY-11234:
-----------------------------------
Summary: Since WildFly 14 i18n ResourceBundle properties file not found if without locale
Key: WFLY-11234
URL: https://issues.jboss.org/browse/WFLY-11234
Project: WildFly
Issue Type: Bug
Affects Versions: 14.0.1.Final
Environment: Ubuntu 18.04, OpenJDK 8 and 11
Reporter: Anton Pussep
Assignee: Jason Greene
As discussed in this thread
https://developer.jboss.org/message/985930
my i18n properties have not been resolved on WildFly 14.0.1.Final - it was working fine through WildFly 10-13, however. I could solve the issue by renaming my properties file from messages.properties to messages_en.properties. Since this solved the issue, I suspect that WildFly 14 does not accept filenames without locale anymore. Since I'm not sure if this is by design, I'm posting this as a bug report here.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
- 1
- 0
[JBoss JIRA] (WFLY-11233) allow EntityManager caching in the JPA container
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-11233?page=com.atlassian.jira.plugin... ]
Scott Marlow updated WFLY-11233:
--------------------------------
Description:
It could be interesting to see if caching EntityManager instances (per EntityManagerFactory) could improve performance for applications, that could benefit from that.
The JPA 2.2 specification mentions the below, pay particular attention to the text "whether entity manager instances are sometimes reused" in section 7.8.2, also look at mention of [88]:
{quote}
7.8 Requirements on the Container
7.8.1 Application-managed Persistence Contexts
When application-managed persistence contexts are used, the container must instantiate the entity manager factory and expose it to the application via JNDI. The container might use internal APIs to create the entity manager factory, or it might use the PersistenceProvider.createContainerEntityManagerFactory method. However, the container is required to support third-party persistence providers, and in this case the container must use the PersistenceProvider.createContainerEntityManagerFactory method to create the entity manager factory and the EntityManagerFactory.close method to destroy the entity manager factory prior to shutdown (if it has not been previously closed by the application).
7.8.2 Container Managed Persistence Contexts
The container is responsible for managing the lifecycle of container-managed persistence contexts, for injecting EntityManager references into web components and session bean and message-driven bean components, and for making EntityManager references available to direct lookups in JNDI. When operating with a third-party persistence provider, the container uses the contracts defined in section 7.9 to create and destroy container-managed persistence contexts. It is undefined whether a new entity manager instance is created for every persistence context, or whether entity manager instances are sometimes reused. Exactly how the container maintains the association between persistence context and JTA transaction is not defined. If a persistence context is already associated with a JTA transaction, the container uses that persistence context for subsequent invocations within the scope of that transaction, according to the semantics for persistence context propagation defined in section 7.6.4.
7.9 Runtime Contracts between the Container and Persistence Provider
This section describes contracts between the container and the persistence provider for the pluggability of third-party persistence providers. Containers are required to support these pluggability contracts. [87]
7.9.1 Container Responsibilities
For the management of a transaction-scoped persistence context, if there is no EntityManager already associated with the JTA transaction:
* The container creates a new entity manager by calling EntityManagerFactory.createEntityManager when the first invocation of an entity manager with PersistenceContextType.TRANSACTION occurs within the scope of a business method executing in the JTA transaction.
* After the JTA transaction has completed (either by transaction commit or rollback), the container closes the entity manager by calling EntityManager.close. [88] Note that the JTA transaction may rollback in a background thread (e.g., as a result of transaction timeout), in which case the container should arrange for the entity manager to be closed but the EntityManager.close method should not be concurrently invoked while the application is in an EntityManager invocation.
The container must throw the TransactionRequiredException if a transaction-scoped persistence context is used and the EntityManager persist, remove, merge, or refresh method is invoked when no transaction is active.
For stateful session beans with extended persistence contexts:
* The container creates an entity manager by calling EntityManagerFactory.createEntityManager when a stateful session bean is created that declares a dependency on an entity manager with PersistenceContextType.EXTENDED. (See section 7.6.3).
* The container closes the entity manager by calling EntityManager.close after the stateful session bean and all other stateful session beans that have inherited the same persistence context as the entity manager have been removed.
* When a business method of the stateful session bean is invoked, if the stateful session bean uses container managed transaction demarcation, and the entity manager is not already associated with the current JTA transaction, the container associates the entity manager with the current JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction. If there is a different persistence context already associated with the JTA transaction, the container throws the EJBException.
* When a business method of the stateful session bean is invoked, if the stateful session bean uses bean managed transaction demarcation and a UserTransaction is begun within the method, the container associates the persistence context with the JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction.
The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.
[87] It is not required that these contracts be used when a third-party persistence provider is not used: the container might use these same APIs or its might use its own internal APIs.
[88] The container may choose to pool EntityManagers: it instead of creating and closing in each case, it may acquire one from its pool and call clear() on it.
{quote}
One challenge with introducing an entity manager (per EntityManagerFactory) cache, is knowing when to close EntityManagers after certain errors have occurred on the EntityManager:
* In [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], we can try to retrieve an entity manager from the cache (cache reference can be passed into the TransactionScopedEntityManager proxy constructor), if cache is empty, then create a new entity manager to return.
* In https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav..., if caching is enabled, we should call EntityManager.clear(), instead of EntityManager.close(), however, if an exception is thrown (on call to em.clear()), the entity manager shouldn't be put in the cache, instead we can try to close it and log/ignore any further exception thrown by the call to em.close().
* If an entity manager is in a bad state, we shouldn't place it back in the cache. This may really be the same as the previous bullet but I wanted to mention it as a separate bullet, since we may need to add more error checking for the persistence throwing exceptions in [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...] or/and other places.
* In [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], if caching is enabled, we should call EntityManager.clear() instead of EntityManager.close(), however, if an exception is thrown (on call to em.clear()), the entity manager shouldn't be put in the cache, instead we can try to close it and log/ignore any any further exception thrown by the call to em.close().
* Lastly, we should update [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], to deal with releasing the entity manager cache before calling entityManagerFactory.close(). Since, [https://docs.oracle.com/javaee/7/api/javax/persistence/EntityManagerFacto...] says that the entity managers will be closed automatically, we probably can just clear the cache of EntityManagers, instead of actually calling EntityManager.close() on each one in the cache.
Also, the reference to the cache of EntityManagers, will be invoked by multiple (concurrent) threads and such, the cache storage should be written to be thread safe.
EntityManager cache settings can be:
* No cache (default)
* ThreadLocal cache (only cached at the application thread level)
* Per EntityManagerFactory cache (cache is shared between multiple threads)
We will also want to specify the EntityManager cache size.
was:
It could be interesting to see if caching EntityManager instances (per EntityManagerFactory) could improve performance for applications, that could benefit from that.
The JPA 2.2 specification mentions the below, pay particular attention to the text "whether entity manager instances are sometimes reused" in section 7.8.2, also look at mention of [88]:
{quote}
7.8 Requirements on the Container
7.8.1 Application-managed Persistence Contexts
When application-managed persistence contexts are used, the container must instantiate the entity manager factory and expose it to the application via JNDI. The container might use internal APIs to create the entity manager factory, or it might use the PersistenceProvider.createContainerEntityManagerFactory method. However, the container is required to support third-party persistence providers, and in this case the container must use the PersistenceProvider.createContainerEntityManagerFactory method to create the entity manager factory and the EntityManagerFactory.close method to destroy the entity manager factory prior to shutdown (if it has not been previously closed by the application).
7.8.2 Container Managed Persistence Contexts
The container is responsible for managing the lifecycle of container-managed persistence contexts, for injecting EntityManager references into web components and session bean and message-driven bean components, and for making EntityManager references available to direct lookups in JNDI. When operating with a third-party persistence provider, the container uses the contracts defined in section 7.9 to create and destroy container-managed persistence contexts. It is undefined whether a new entity manager instance is created for every persistence context, or whether entity manager instances are sometimes reused. Exactly how the container maintains the association between persistence context and JTA transaction is not defined. If a persistence context is already associated with a JTA transaction, the container uses that persistence context for subsequent invocations within the scope of that transaction, according to the semantics for persistence context propagation defined in section 7.6.4.
7.9 Runtime Contracts between the Container and Persistence Provider
This section describes contracts between the container and the persistence provider for the pluggability of third-party persistence providers. Containers are required to support these pluggability contracts. [87]
7.9.1 Container Responsibilities
For the management of a transaction-scoped persistence context, if there is no EntityManager already associated with the JTA transaction:
* The container creates a new entity manager by calling EntityManagerFactory.createEntityManager when the first invocation of an entity manager with PersistenceContextType.TRANSACTION occurs within the scope of a business method executing in the JTA transaction.
* After the JTA transaction has completed (either by transaction commit or rollback), the container closes the entity manager by calling EntityManager.close. [88] Note that the JTA transaction may rollback in a background thread (e.g., as a result of transaction timeout), in which case the container should arrange for the entity manager to be closed but the EntityManager.close method should not be concurrently invoked while the application is in an EntityManager invocation.
The container must throw the TransactionRequiredException if a transaction-scoped persistence context is used and the EntityManager persist, remove, merge, or refresh method is invoked when no transaction is active.
For stateful session beans with extended persistence contexts:
* The container creates an entity manager by calling EntityManagerFactory.createEntityManager when a stateful session bean is created that declares a dependency on an entity manager with PersistenceContextType.EXTENDED. (See section 7.6.3).
* The container closes the entity manager by calling EntityManager.close after the stateful session bean and all other stateful session beans that have inherited the same persistence context as the entity manager have been removed.
* When a business method of the stateful session bean is invoked, if the stateful session bean uses container managed transaction demarcation, and the entity manager is not already associated with the current JTA transaction, the container associates the entity manager with the current JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction. If there is a different persistence context already associated with the JTA transaction, the container throws the EJBException.
* When a business method of the stateful session bean is invoked, if the stateful session bean uses bean managed transaction demarcation and a UserTransaction is begun within the method, the container associates the persistence context with the JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction.
The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.
[87] It is not required that these contracts be used when a third-party persistence provider is not used: the container might use these same APIs or its might use its own internal APIs.
[88] The container may choose to pool EntityManagers: it instead of creating and closing in each case, it may acquire one from its pool and call clear() on it.
{quote}
One challenge with introducing an entity manager (per EntityManagerFactory) cache, is knowing when to close EntityManagers after certain errors have occurred on the EntityManager:
* In [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], we can try to retrieve an entity manager from the cache (cache reference can be passed into the TransactionScopedEntityManager proxy constructor), if cache is empty, then create a new entity manager to return.
* In https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav..., if caching is enabled, we should call EntityManager.clear(), instead of EntityManager.close(), however, if an exception is thrown (on call to em.clear()), the entity manager shouldn't be put in the cache, instead we can try to close it and log/ignore any further exception thrown by the call to em.close().
* If an entity manager is in a bad state, we shouldn't place it back in the cache. This may really be the same as the previous bullet but I wanted to mention it as a separate bullet, since we may need to add more error checking for the persistence throwing exceptions in [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...] or/and other places.
* In [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], if caching is enabled, we should call EntityManager.clear() instead of EntityManager.close(), however, if an exception is thrown (on call to em.clear()), the entity manager shouldn't be put in the cache, instead we can try to close it and log/ignore any any further exception thrown by the call to em.close().
* Lastly, we should update [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], to deal with releasing the entity manager cache before calling entityManagerFactory.close(). Since, [https://docs.oracle.com/javaee/7/api/javax/persistence/EntityManagerFacto...] says that the entity managers will be closed automatically, we probably can just clear the cache of EntityManagers, instead of actually calling EntityManager.close() on each one in the cache.
Also, the reference to the cache of EntityManagers, will be invoked by multiple (concurrent) threads and such, the cache storage should be written to be thread safe.
EntityManager cache settings can be:
* No cache (default)
* ThreadLocal cache (only cached at the application thread level)
* Per EntityManagerFactory cache (cache is shared between multiple threads)
> allow EntityManager caching in the JPA container
> ------------------------------------------------
>
> Key: WFLY-11233
> URL: https://issues.jboss.org/browse/WFLY-11233
> Project: WildFly
> Issue Type: Enhancement
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Priority: Major
>
> It could be interesting to see if caching EntityManager instances (per EntityManagerFactory) could improve performance for applications, that could benefit from that.
> The JPA 2.2 specification mentions the below, pay particular attention to the text "whether entity manager instances are sometimes reused" in section 7.8.2, also look at mention of [88]:
> {quote}
> 7.8 Requirements on the Container
> 7.8.1 Application-managed Persistence Contexts
> When application-managed persistence contexts are used, the container must instantiate the entity manager factory and expose it to the application via JNDI. The container might use internal APIs to create the entity manager factory, or it might use the PersistenceProvider.createContainerEntityManagerFactory method. However, the container is required to support third-party persistence providers, and in this case the container must use the PersistenceProvider.createContainerEntityManagerFactory method to create the entity manager factory and the EntityManagerFactory.close method to destroy the entity manager factory prior to shutdown (if it has not been previously closed by the application).
> 7.8.2 Container Managed Persistence Contexts
> The container is responsible for managing the lifecycle of container-managed persistence contexts, for injecting EntityManager references into web components and session bean and message-driven bean components, and for making EntityManager references available to direct lookups in JNDI. When operating with a third-party persistence provider, the container uses the contracts defined in section 7.9 to create and destroy container-managed persistence contexts. It is undefined whether a new entity manager instance is created for every persistence context, or whether entity manager instances are sometimes reused. Exactly how the container maintains the association between persistence context and JTA transaction is not defined. If a persistence context is already associated with a JTA transaction, the container uses that persistence context for subsequent invocations within the scope of that transaction, according to the semantics for persistence context propagation defined in section 7.6.4.
> 7.9 Runtime Contracts between the Container and Persistence Provider
> This section describes contracts between the container and the persistence provider for the pluggability of third-party persistence providers. Containers are required to support these pluggability contracts. [87]
> 7.9.1 Container Responsibilities
> For the management of a transaction-scoped persistence context, if there is no EntityManager already associated with the JTA transaction:
> * The container creates a new entity manager by calling EntityManagerFactory.createEntityManager when the first invocation of an entity manager with PersistenceContextType.TRANSACTION occurs within the scope of a business method executing in the JTA transaction.
> * After the JTA transaction has completed (either by transaction commit or rollback), the container closes the entity manager by calling EntityManager.close. [88] Note that the JTA transaction may rollback in a background thread (e.g., as a result of transaction timeout), in which case the container should arrange for the entity manager to be closed but the EntityManager.close method should not be concurrently invoked while the application is in an EntityManager invocation.
> The container must throw the TransactionRequiredException if a transaction-scoped persistence context is used and the EntityManager persist, remove, merge, or refresh method is invoked when no transaction is active.
> For stateful session beans with extended persistence contexts:
> * The container creates an entity manager by calling EntityManagerFactory.createEntityManager when a stateful session bean is created that declares a dependency on an entity manager with PersistenceContextType.EXTENDED. (See section 7.6.3).
> * The container closes the entity manager by calling EntityManager.close after the stateful session bean and all other stateful session beans that have inherited the same persistence context as the entity manager have been removed.
> * When a business method of the stateful session bean is invoked, if the stateful session bean uses container managed transaction demarcation, and the entity manager is not already associated with the current JTA transaction, the container associates the entity manager with the current JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction. If there is a different persistence context already associated with the JTA transaction, the container throws the EJBException.
> * When a business method of the stateful session bean is invoked, if the stateful session bean uses bean managed transaction demarcation and a UserTransaction is begun within the method, the container associates the persistence context with the JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction.
> The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.
> [87] It is not required that these contracts be used when a third-party persistence provider is not used: the container might use these same APIs or its might use its own internal APIs.
> [88] The container may choose to pool EntityManagers: it instead of creating and closing in each case, it may acquire one from its pool and call clear() on it.
> {quote}
> One challenge with introducing an entity manager (per EntityManagerFactory) cache, is knowing when to close EntityManagers after certain errors have occurred on the EntityManager:
> * In [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], we can try to retrieve an entity manager from the cache (cache reference can be passed into the TransactionScopedEntityManager proxy constructor), if cache is empty, then create a new entity manager to return.
> * In https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav..., if caching is enabled, we should call EntityManager.clear(), instead of EntityManager.close(), however, if an exception is thrown (on call to em.clear()), the entity manager shouldn't be put in the cache, instead we can try to close it and log/ignore any further exception thrown by the call to em.close().
> * If an entity manager is in a bad state, we shouldn't place it back in the cache. This may really be the same as the previous bullet but I wanted to mention it as a separate bullet, since we may need to add more error checking for the persistence throwing exceptions in [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...] or/and other places.
> * In [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], if caching is enabled, we should call EntityManager.clear() instead of EntityManager.close(), however, if an exception is thrown (on call to em.clear()), the entity manager shouldn't be put in the cache, instead we can try to close it and log/ignore any any further exception thrown by the call to em.close().
> * Lastly, we should update [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], to deal with releasing the entity manager cache before calling entityManagerFactory.close(). Since, [https://docs.oracle.com/javaee/7/api/javax/persistence/EntityManagerFacto...] says that the entity managers will be closed automatically, we probably can just clear the cache of EntityManagers, instead of actually calling EntityManager.close() on each one in the cache.
> Also, the reference to the cache of EntityManagers, will be invoked by multiple (concurrent) threads and such, the cache storage should be written to be thread safe.
> EntityManager cache settings can be:
> * No cache (default)
> * ThreadLocal cache (only cached at the application thread level)
> * Per EntityManagerFactory cache (cache is shared between multiple threads)
> We will also want to specify the EntityManager cache size.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
- 1
- 0
[JBoss JIRA] (WFLY-11233) allow EntityManager caching in the JPA container
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-11233?page=com.atlassian.jira.plugin... ]
Scott Marlow updated WFLY-11233:
--------------------------------
Description:
It could be interesting to see if caching EntityManager instances (per EntityManagerFactory) could improve performance for applications, that could benefit from that.
The JPA 2.2 specification mentions the below, pay particular attention to the text "whether entity manager instances are sometimes reused" in section 7.8.2, also look at mention of [88]:
{quote}
7.8 Requirements on the Container
7.8.1 Application-managed Persistence Contexts
When application-managed persistence contexts are used, the container must instantiate the entity manager factory and expose it to the application via JNDI. The container might use internal APIs to create the entity manager factory, or it might use the PersistenceProvider.createContainerEntityManagerFactory method. However, the container is required to support third-party persistence providers, and in this case the container must use the PersistenceProvider.createContainerEntityManagerFactory method to create the entity manager factory and the EntityManagerFactory.close method to destroy the entity manager factory prior to shutdown (if it has not been previously closed by the application).
7.8.2 Container Managed Persistence Contexts
The container is responsible for managing the lifecycle of container-managed persistence contexts, for injecting EntityManager references into web components and session bean and message-driven bean components, and for making EntityManager references available to direct lookups in JNDI. When operating with a third-party persistence provider, the container uses the contracts defined in section 7.9 to create and destroy container-managed persistence contexts. It is undefined whether a new entity manager instance is created for every persistence context, or whether entity manager instances are sometimes reused. Exactly how the container maintains the association between persistence context and JTA transaction is not defined. If a persistence context is already associated with a JTA transaction, the container uses that persistence context for subsequent invocations within the scope of that transaction, according to the semantics for persistence context propagation defined in section 7.6.4.
7.9 Runtime Contracts between the Container and Persistence Provider
This section describes contracts between the container and the persistence provider for the pluggability of third-party persistence providers. Containers are required to support these pluggability contracts. [87]
7.9.1 Container Responsibilities
For the management of a transaction-scoped persistence context, if there is no EntityManager already associated with the JTA transaction:
* The container creates a new entity manager by calling EntityManagerFactory.createEntityManager when the first invocation of an entity manager with PersistenceContextType.TRANSACTION occurs within the scope of a business method executing in the JTA transaction.
* After the JTA transaction has completed (either by transaction commit or rollback), the container closes the entity manager by calling EntityManager.close. [88] Note that the JTA transaction may rollback in a background thread (e.g., as a result of transaction timeout), in which case the container should arrange for the entity manager to be closed but the EntityManager.close method should not be concurrently invoked while the application is in an EntityManager invocation.
The container must throw the TransactionRequiredException if a transaction-scoped persistence context is used and the EntityManager persist, remove, merge, or refresh method is invoked when no transaction is active.
For stateful session beans with extended persistence contexts:
* The container creates an entity manager by calling EntityManagerFactory.createEntityManager when a stateful session bean is created that declares a dependency on an entity manager with PersistenceContextType.EXTENDED. (See section 7.6.3).
* The container closes the entity manager by calling EntityManager.close after the stateful session bean and all other stateful session beans that have inherited the same persistence context as the entity manager have been removed.
* When a business method of the stateful session bean is invoked, if the stateful session bean uses container managed transaction demarcation, and the entity manager is not already associated with the current JTA transaction, the container associates the entity manager with the current JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction. If there is a different persistence context already associated with the JTA transaction, the container throws the EJBException.
* When a business method of the stateful session bean is invoked, if the stateful session bean uses bean managed transaction demarcation and a UserTransaction is begun within the method, the container associates the persistence context with the JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction.
The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.
[87] It is not required that these contracts be used when a third-party persistence provider is not used: the container might use these same APIs or its might use its own internal APIs.
[88] The container may choose to pool EntityManagers: it instead of creating and closing in each case, it may acquire one from its pool and call clear() on it.
{quote}
One challenge with introducing an entity manager (per EntityManagerFactory) cache, is knowing when to close EntityManagers after certain errors have occurred on the EntityManager:
* In [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], we can try to retrieve an entity manager from the cache (cache reference can be passed into the TransactionScopedEntityManager proxy constructor), if cache is empty, then create a new entity manager to return.
* In https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav..., if caching is enabled, we should call EntityManager.clear(), instead of EntityManager.close(), however, if an exception is thrown (on call to em.clear()), the entity manager shouldn't be put in the cache, instead we can try to close it and log/ignore any further exception thrown by the call to em.close().
* If an entity manager is in a bad state, we shouldn't place it back in the cache. This may really be the same as the previous bullet but I wanted to mention it as a separate bullet, since we may need to add more error checking for the persistence throwing exceptions in [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...] or/and other places.
* In [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], if caching is enabled, we should call EntityManager.clear() instead of EntityManager.close(), however, if an exception is thrown (on call to em.clear()), the entity manager shouldn't be put in the cache, instead we can try to close it and log/ignore any any further exception thrown by the call to em.close().
* Lastly, we should update [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], to deal with releasing the entity manager cache before calling entityManagerFactory.close(). Since, [https://docs.oracle.com/javaee/7/api/javax/persistence/EntityManagerFacto...] says that the entity managers will be closed automatically, we probably can just clear the cache of EntityManagers, instead of actually calling EntityManager.close() on each one in the cache.
Also, the reference to the cache of EntityManagers, will be invoked by multiple (concurrent) threads and such, the cache storage should be written to be thread safe.
EntityManager cache settings can be:
* No cache (default)
* ThreadLocal cache (only cached at the application thread level)
* Per EntityManagerFactory cache (cache is shared between multiple threads)
was:
It could be interesting to see if caching EntityManager instances (per EntityManagerFactory) could improve performance for applications, that could benefit from that.
The JPA 2.2 specification mentions the below, pay particular attention to the text "whether entity manager instances are sometimes reused" in section 7.8.2, also look at mention of [88]:
{quote}
7.8 Requirements on the Container
7.8.1 Application-managed Persistence Contexts
When application-managed persistence contexts are used, the container must instantiate the entity manager factory and expose it to the application via JNDI. The container might use internal APIs to create the entity manager factory, or it might use the PersistenceProvider.createContainerEntityManagerFactory method. However, the container is required to support third-party persistence providers, and in this case the container must use the PersistenceProvider.createContainerEntityManagerFactory method to create the entity manager factory and the EntityManagerFactory.close method to destroy the entity manager factory prior to shutdown (if it has not been previously closed by the application).
7.8.2 Container Managed Persistence Contexts
The container is responsible for managing the lifecycle of container-managed persistence contexts, for injecting EntityManager references into web components and session bean and message-driven bean components, and for making EntityManager references available to direct lookups in JNDI. When operating with a third-party persistence provider, the container uses the contracts defined in section 7.9 to create and destroy container-managed persistence contexts. It is undefined whether a new entity manager instance is created for every persistence context, or whether entity manager instances are sometimes reused. Exactly how the container maintains the association between persistence context and JTA transaction is not defined. If a persistence context is already associated with a JTA transaction, the container uses that persistence context for subsequent invocations within the scope of that transaction, according to the semantics for persistence context propagation defined in section 7.6.4.
7.9 Runtime Contracts between the Container and Persistence Provider
This section describes contracts between the container and the persistence provider for the pluggability of third-party persistence providers. Containers are required to support these pluggability contracts. [87]
7.9.1 Container Responsibilities
For the management of a transaction-scoped persistence context, if there is no EntityManager already associated with the JTA transaction:
* The container creates a new entity manager by calling EntityManagerFactory.createEntityManager when the first invocation of an entity manager with PersistenceContextType.TRANSACTION occurs within the scope of a business method executing in the JTA transaction.
* After the JTA transaction has completed (either by transaction commit or rollback), the container closes the entity manager by calling EntityManager.close. [88] Note that the JTA transaction may rollback in a background thread (e.g., as a result of transaction timeout), in which case the container should arrange for the entity manager to be closed but the EntityManager.close method should not be concurrently invoked while the application is in an EntityManager invocation.
The container must throw the TransactionRequiredException if a transaction-scoped persistence context is used and the EntityManager persist, remove, merge, or refresh method is invoked when no transaction is active.
For stateful session beans with extended persistence contexts:
* The container creates an entity manager by calling EntityManagerFactory.createEntityManager when a stateful session bean is created that declares a dependency on an entity manager with PersistenceContextType.EXTENDED. (See section 7.6.3).
* The container closes the entity manager by calling EntityManager.close after the stateful session bean and all other stateful session beans that have inherited the same persistence context as the entity manager have been removed.
* When a business method of the stateful session bean is invoked, if the stateful session bean uses container managed transaction demarcation, and the entity manager is not already associated with the current JTA transaction, the container associates the entity manager with the current JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction. If there is a different persistence context already associated with the JTA transaction, the container throws the EJBException.
* When a business method of the stateful session bean is invoked, if the stateful session bean uses bean managed transaction demarcation and a UserTransaction is begun within the method, the container associates the persistence context with the JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction.
The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.
[87] It is not required that these contracts be used when a third-party persistence provider is not used: the container might use these same APIs or its might use its own internal APIs.
[88] The container may choose to pool EntityManagers: it instead of creating and closing in each case, it may acquire one from its pool and call clear() on it.
{quote}
One challenge with introducing an entity manager (per EntityManagerFactory) cache, is knowing when to close EntityManagers after certain errors have occurred on the EntityManager:
* In [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], we can try to retrieve an entity manager from the cache (cache reference can be passed into the TransactionScopedEntityManager proxy constructor), if cache is empty, then create a new entity manager to return.
* In https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav..., if caching is enabled, we should call EntityManager.clear(), instead of EntityManager.close(), however, if an exception is thrown (on call to em.clear()), the entity manager shouldn't be put in the cache, instead we can try to close it and log/ignore any further exception thrown by the call to em.close().
* If an entity manager is in a bad state, we shouldn't place it back in the cache. This may really be the same as the previous bullet but I wanted to mention it as a separate bullet, since we may need to add more error checking for the persistence throwing exceptions in [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...] or/and other places.
* In [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], if caching is enabled, we should call EntityManager.clear() instead of EntityManager.close(), however, if an exception is thrown (on call to em.clear()), the entity manager shouldn't be put in the cache, instead we can try to close it and log/ignore any any further exception thrown by the call to em.close().
* Lastly, we should update [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], to deal with releasing the entity manager cache before calling entityManagerFactory.close(). Since, [https://docs.oracle.com/javaee/7/api/javax/persistence/EntityManagerFacto...] says that the entity managers will be closed automatically, we probably can just clear the cache of EntityManagers, instead of actually calling EntityManager.close() on each one in the cache.
Also, the reference to the cache of EntityManagers, will be invoked by multiple (concurrent) threads and such, the cache storage should be written to be thread safe.
> allow EntityManager caching in the JPA container
> ------------------------------------------------
>
> Key: WFLY-11233
> URL: https://issues.jboss.org/browse/WFLY-11233
> Project: WildFly
> Issue Type: Enhancement
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Priority: Major
>
> It could be interesting to see if caching EntityManager instances (per EntityManagerFactory) could improve performance for applications, that could benefit from that.
> The JPA 2.2 specification mentions the below, pay particular attention to the text "whether entity manager instances are sometimes reused" in section 7.8.2, also look at mention of [88]:
> {quote}
> 7.8 Requirements on the Container
> 7.8.1 Application-managed Persistence Contexts
> When application-managed persistence contexts are used, the container must instantiate the entity manager factory and expose it to the application via JNDI. The container might use internal APIs to create the entity manager factory, or it might use the PersistenceProvider.createContainerEntityManagerFactory method. However, the container is required to support third-party persistence providers, and in this case the container must use the PersistenceProvider.createContainerEntityManagerFactory method to create the entity manager factory and the EntityManagerFactory.close method to destroy the entity manager factory prior to shutdown (if it has not been previously closed by the application).
> 7.8.2 Container Managed Persistence Contexts
> The container is responsible for managing the lifecycle of container-managed persistence contexts, for injecting EntityManager references into web components and session bean and message-driven bean components, and for making EntityManager references available to direct lookups in JNDI. When operating with a third-party persistence provider, the container uses the contracts defined in section 7.9 to create and destroy container-managed persistence contexts. It is undefined whether a new entity manager instance is created for every persistence context, or whether entity manager instances are sometimes reused. Exactly how the container maintains the association between persistence context and JTA transaction is not defined. If a persistence context is already associated with a JTA transaction, the container uses that persistence context for subsequent invocations within the scope of that transaction, according to the semantics for persistence context propagation defined in section 7.6.4.
> 7.9 Runtime Contracts between the Container and Persistence Provider
> This section describes contracts between the container and the persistence provider for the pluggability of third-party persistence providers. Containers are required to support these pluggability contracts. [87]
> 7.9.1 Container Responsibilities
> For the management of a transaction-scoped persistence context, if there is no EntityManager already associated with the JTA transaction:
> * The container creates a new entity manager by calling EntityManagerFactory.createEntityManager when the first invocation of an entity manager with PersistenceContextType.TRANSACTION occurs within the scope of a business method executing in the JTA transaction.
> * After the JTA transaction has completed (either by transaction commit or rollback), the container closes the entity manager by calling EntityManager.close. [88] Note that the JTA transaction may rollback in a background thread (e.g., as a result of transaction timeout), in which case the container should arrange for the entity manager to be closed but the EntityManager.close method should not be concurrently invoked while the application is in an EntityManager invocation.
> The container must throw the TransactionRequiredException if a transaction-scoped persistence context is used and the EntityManager persist, remove, merge, or refresh method is invoked when no transaction is active.
> For stateful session beans with extended persistence contexts:
> * The container creates an entity manager by calling EntityManagerFactory.createEntityManager when a stateful session bean is created that declares a dependency on an entity manager with PersistenceContextType.EXTENDED. (See section 7.6.3).
> * The container closes the entity manager by calling EntityManager.close after the stateful session bean and all other stateful session beans that have inherited the same persistence context as the entity manager have been removed.
> * When a business method of the stateful session bean is invoked, if the stateful session bean uses container managed transaction demarcation, and the entity manager is not already associated with the current JTA transaction, the container associates the entity manager with the current JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction. If there is a different persistence context already associated with the JTA transaction, the container throws the EJBException.
> * When a business method of the stateful session bean is invoked, if the stateful session bean uses bean managed transaction demarcation and a UserTransaction is begun within the method, the container associates the persistence context with the JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction.
> The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.
> [87] It is not required that these contracts be used when a third-party persistence provider is not used: the container might use these same APIs or its might use its own internal APIs.
> [88] The container may choose to pool EntityManagers: it instead of creating and closing in each case, it may acquire one from its pool and call clear() on it.
> {quote}
> One challenge with introducing an entity manager (per EntityManagerFactory) cache, is knowing when to close EntityManagers after certain errors have occurred on the EntityManager:
> * In [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], we can try to retrieve an entity manager from the cache (cache reference can be passed into the TransactionScopedEntityManager proxy constructor), if cache is empty, then create a new entity manager to return.
> * In https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav..., if caching is enabled, we should call EntityManager.clear(), instead of EntityManager.close(), however, if an exception is thrown (on call to em.clear()), the entity manager shouldn't be put in the cache, instead we can try to close it and log/ignore any further exception thrown by the call to em.close().
> * If an entity manager is in a bad state, we shouldn't place it back in the cache. This may really be the same as the previous bullet but I wanted to mention it as a separate bullet, since we may need to add more error checking for the persistence throwing exceptions in [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...] or/and other places.
> * In [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], if caching is enabled, we should call EntityManager.clear() instead of EntityManager.close(), however, if an exception is thrown (on call to em.clear()), the entity manager shouldn't be put in the cache, instead we can try to close it and log/ignore any any further exception thrown by the call to em.close().
> * Lastly, we should update [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], to deal with releasing the entity manager cache before calling entityManagerFactory.close(). Since, [https://docs.oracle.com/javaee/7/api/javax/persistence/EntityManagerFacto...] says that the entity managers will be closed automatically, we probably can just clear the cache of EntityManagers, instead of actually calling EntityManager.close() on each one in the cache.
> Also, the reference to the cache of EntityManagers, will be invoked by multiple (concurrent) threads and such, the cache storage should be written to be thread safe.
> EntityManager cache settings can be:
> * No cache (default)
> * ThreadLocal cache (only cached at the application thread level)
> * Per EntityManagerFactory cache (cache is shared between multiple threads)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
- 1
- 0
[JBoss JIRA] (WFLY-11233) allow EntityManager caching in the JPA container
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-11233?page=com.atlassian.jira.plugin... ]
Scott Marlow updated WFLY-11233:
--------------------------------
Description:
It could be interesting to see if caching EntityManager instances (per EntityManagerFactory) could improve performance for applications, that could benefit from that.
The JPA 2.2 specification mentions the below, pay particular attention to the text "whether entity manager instances are sometimes reused" in section 7.8.2, also look at mention of [88]:
{quote}
7.8 Requirements on the Container
7.8.1 Application-managed Persistence Contexts
When application-managed persistence contexts are used, the container must instantiate the entity manager factory and expose it to the application via JNDI. The container might use internal APIs to create the entity manager factory, or it might use the PersistenceProvider.createContainerEntityManagerFactory method. However, the container is required to support third-party persistence providers, and in this case the container must use the PersistenceProvider.createContainerEntityManagerFactory method to create the entity manager factory and the EntityManagerFactory.close method to destroy the entity manager factory prior to shutdown (if it has not been previously closed by the application).
7.8.2 Container Managed Persistence Contexts
The container is responsible for managing the lifecycle of container-managed persistence contexts, for injecting EntityManager references into web components and session bean and message-driven bean components, and for making EntityManager references available to direct lookups in JNDI. When operating with a third-party persistence provider, the container uses the contracts defined in section 7.9 to create and destroy container-managed persistence contexts. It is undefined whether a new entity manager instance is created for every persistence context, or whether entity manager instances are sometimes reused. Exactly how the container maintains the association between persistence context and JTA transaction is not defined. If a persistence context is already associated with a JTA transaction, the container uses that persistence context for subsequent invocations within the scope of that transaction, according to the semantics for persistence context propagation defined in section 7.6.4.
7.9 Runtime Contracts between the Container and Persistence Provider
This section describes contracts between the container and the persistence provider for the pluggability of third-party persistence providers. Containers are required to support these pluggability contracts. [87]
7.9.1 Container Responsibilities
For the management of a transaction-scoped persistence context, if there is no EntityManager already associated with the JTA transaction:
* The container creates a new entity manager by calling EntityManagerFactory.createEntityManager when the first invocation of an entity manager with PersistenceContextType.TRANSACTION occurs within the scope of a business method executing in the JTA transaction.
* After the JTA transaction has completed (either by transaction commit or rollback), the container closes the entity manager by calling EntityManager.close. [88] Note that the JTA transaction may rollback in a background thread (e.g., as a result of transaction timeout), in which case the container should arrange for the entity manager to be closed but the EntityManager.close method should not be concurrently invoked while the application is in an EntityManager invocation.
The container must throw the TransactionRequiredException if a transaction-scoped persistence context is used and the EntityManager persist, remove, merge, or refresh method is invoked when no transaction is active.
For stateful session beans with extended persistence contexts:
* The container creates an entity manager by calling EntityManagerFactory.createEntityManager when a stateful session bean is created that declares a dependency on an entity manager with PersistenceContextType.EXTENDED. (See section 7.6.3).
* The container closes the entity manager by calling EntityManager.close after the stateful session bean and all other stateful session beans that have inherited the same persistence context as the entity manager have been removed.
* When a business method of the stateful session bean is invoked, if the stateful session bean uses container managed transaction demarcation, and the entity manager is not already associated with the current JTA transaction, the container associates the entity manager with the current JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction. If there is a different persistence context already associated with the JTA transaction, the container throws the EJBException.
* When a business method of the stateful session bean is invoked, if the stateful session bean uses bean managed transaction demarcation and a UserTransaction is begun within the method, the container associates the persistence context with the JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction.
The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.
[87] It is not required that these contracts be used when a third-party persistence provider is not used: the container might use these same APIs or its might use its own internal APIs.
[88] The container may choose to pool EntityManagers: it instead of creating and closing in each case, it may acquire one from its pool and call clear() on it.
{quote}
One challenge with introducing an entity manager (per EntityManagerFactory) cache, is knowing when to close EntityManagers after certain errors have occurred on the EntityManager:
* In [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], we can try to retrieve an entity manager from the cache (cache reference can be passed into the TransactionScopedEntityManager proxy constructor), if cache is empty, then create a new entity manager to return.
* In https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav..., if caching is enabled, we should call EntityManager.clear(), instead of EntityManager.close(), however, if an exception is thrown (on call to em.clear()), the entity manager shouldn't be put in the cache, instead we can try to close it and log/ignore any further exception thrown by the call to em.close().
* If an entity manager is in a bad state, we shouldn't place it back in the cache. This may really be the same as the previous bullet but I wanted to mention it as a separate bullet, since we may need to add more error checking for the persistence throwing exceptions in [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...] or/and other places.
* In [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], if caching is enabled, we should call EntityManager.clear() instead of EntityManager.close(), however, if an exception is thrown (on call to em.clear()), the entity manager shouldn't be put in the cache, instead we can try to close it and log/ignore any any further exception thrown by the call to em.close().
* Lastly, we should update [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], to deal with releasing the entity manager cache before calling entityManagerFactory.close(). Since, [https://docs.oracle.com/javaee/7/api/javax/persistence/EntityManagerFacto...] says that the entity managers will be closed automatically, we probably can just clear the cache of EntityManagers, instead of actually calling EntityManager.close() on each one in the cache.
Also, the reference to the cache of EntityManagers, will be invoked by multiple (concurrent) threads and such, the cache storage should be written to be thread safe.
was:
It could be interesting to see if caching EntityManager instances (per EntityManagerFactory) could improve performance for applications, that could benefit from that.
The JPA 2.2 specification mentions the below, pay particular attention to the text "whether entity manager instances are sometimes reused" in section 7.8.2, also look at mention of [88]:
{quote}
7.8 Requirements on the Container
7.8.1 Application-managed Persistence Contexts
When application-managed persistence contexts are used, the container must instantiate the entity manager factory and expose it to the application via JNDI. The container might use internal APIs to create the entity manager factory, or it might use the PersistenceProvider.createContainerEntityManagerFactory method. However, the container is required to support third-party persistence providers, and in this case the container must use the PersistenceProvider.createContainerEntityManagerFactory method to create the entity manager factory and the EntityManagerFactory.close method to destroy the entity manager factory prior to shutdown (if it has not been previously closed by the application).
7.8.2 Container Managed Persistence Contexts
The container is responsible for managing the lifecycle of container-managed persistence contexts, for injecting EntityManager references into web components and session bean and message-driven bean components, and for making EntityManager references available to direct lookups in JNDI. When operating with a third-party persistence provider, the container uses the contracts defined in section 7.9 to create and destroy container-managed persistence contexts. It is undefined whether a new entity manager instance is created for every persistence context, or whether entity manager instances are sometimes reused. Exactly how the container maintains the association between persistence context and JTA transaction is not defined. If a persistence context is already associated with a JTA transaction, the container uses that persistence context for subsequent invocations within the scope of that transaction, according to the semantics for persistence context propagation defined in section 7.6.4.
7.9 Runtime Contracts between the Container and Persistence Provider
This section describes contracts between the container and the persistence provider for the pluggability of third-party persistence providers. Containers are required to support these pluggability contracts. [87]
7.9.1 Container Responsibilities
For the management of a transaction-scoped persistence context, if there is no EntityManager already associated with the JTA transaction:
* The container creates a new entity manager by calling EntityManagerFactory.createEntityManager when the first invocation of an entity manager with PersistenceContextType.TRANSACTION occurs within the scope of a business method executing in the JTA transaction.
* After the JTA transaction has completed (either by transaction commit or rollback), the container closes the entity manager by calling EntityManager.close. [88] Note that the JTA transaction may rollback in a background thread (e.g., as a result of transaction timeout), in which case the container should arrange for the entity manager to be closed but the EntityManager.close method should not be concurrently invoked while the application is in an EntityManager invocation.
The container must throw the TransactionRequiredException if a transaction-scoped persistence context is used and the EntityManager persist, remove, merge, or refresh method is invoked when no transaction is active.
For stateful session beans with extended persistence contexts:
* The container creates an entity manager by calling EntityManagerFactory.createEntityManager when a stateful session bean is created that declares a dependency on an entity manager with PersistenceContextType.EXTENDED. (See section 7.6.3).
* The container closes the entity manager by calling EntityManager.close after the stateful session bean and all other stateful session beans that have inherited the same persistence context as the entity manager have been removed.
* When a business method of the stateful session bean is invoked, if the stateful session bean uses container managed transaction demarcation, and the entity manager is not already associated with the current JTA transaction, the container associates the entity manager with the current JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction. If there is a different persistence context already associated with the JTA transaction, the container throws the EJBException.
* When a business method of the stateful session bean is invoked, if the stateful session bean uses bean managed transaction demarcation and a UserTransaction is begun within the method, the container associates the persistence context with the JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction.
The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.
[87] It is not required that these contracts be used when a third-party persistence provider is not used: the container might use these same APIs or its might use its own internal APIs.
[88] The container may choose to pool EntityManagers: it instead of creating and closing in each case, it may acquire one from its pool and call clear() on it.
{quote}
One challenge with introducing an entity manager (per EntityManagerFactory) cache, is knowing when to close EntityManagers after certain errors have occurred on the EntityManager:
* In https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav..., if caching is enabled, we should call EntityManager.clear(), instead of EntityManager.close(), however, if an exception is thrown (on call to em.clear()), the entity manager shouldn't be put in the cache, instead we can try to close it and log/ignore any further exception thrown by the call to em.close().
* If an entity manager is in a bad state, we shouldn't place it back in the cache. This may really be the same as the previous bullet but I wanted to mention it as a separate bullet, since we may need to add more error checking for the persistence throwing exceptions in [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...] or/and other places.
* In [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], if caching is enabled, we should call EntityManager.clear() instead of EntityManager.close(), however, if an exception is thrown (on call to em.clear()), the entity manager shouldn't be put in the cache, instead we can try to close it and log/ignore any any further exception thrown by the call to em.close().
* Lastly, we should update [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], to deal with releasing the entity manager cache before calling entityManagerFactory.close(). Since, [https://docs.oracle.com/javaee/7/api/javax/persistence/EntityManagerFacto...] says that the entity managers will be closed automatically, we probably can just clear the cache of EntityManagers, instead of actually calling EntityManager.close() on each one in the cache.
Also, the reference to the cache of EntityManagers, will be invoked by multiple (concurrent) threads and such, the cache storage should be written to be thread safe.
> allow EntityManager caching in the JPA container
> ------------------------------------------------
>
> Key: WFLY-11233
> URL: https://issues.jboss.org/browse/WFLY-11233
> Project: WildFly
> Issue Type: Enhancement
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Priority: Major
>
> It could be interesting to see if caching EntityManager instances (per EntityManagerFactory) could improve performance for applications, that could benefit from that.
> The JPA 2.2 specification mentions the below, pay particular attention to the text "whether entity manager instances are sometimes reused" in section 7.8.2, also look at mention of [88]:
> {quote}
> 7.8 Requirements on the Container
> 7.8.1 Application-managed Persistence Contexts
> When application-managed persistence contexts are used, the container must instantiate the entity manager factory and expose it to the application via JNDI. The container might use internal APIs to create the entity manager factory, or it might use the PersistenceProvider.createContainerEntityManagerFactory method. However, the container is required to support third-party persistence providers, and in this case the container must use the PersistenceProvider.createContainerEntityManagerFactory method to create the entity manager factory and the EntityManagerFactory.close method to destroy the entity manager factory prior to shutdown (if it has not been previously closed by the application).
> 7.8.2 Container Managed Persistence Contexts
> The container is responsible for managing the lifecycle of container-managed persistence contexts, for injecting EntityManager references into web components and session bean and message-driven bean components, and for making EntityManager references available to direct lookups in JNDI. When operating with a third-party persistence provider, the container uses the contracts defined in section 7.9 to create and destroy container-managed persistence contexts. It is undefined whether a new entity manager instance is created for every persistence context, or whether entity manager instances are sometimes reused. Exactly how the container maintains the association between persistence context and JTA transaction is not defined. If a persistence context is already associated with a JTA transaction, the container uses that persistence context for subsequent invocations within the scope of that transaction, according to the semantics for persistence context propagation defined in section 7.6.4.
> 7.9 Runtime Contracts between the Container and Persistence Provider
> This section describes contracts between the container and the persistence provider for the pluggability of third-party persistence providers. Containers are required to support these pluggability contracts. [87]
> 7.9.1 Container Responsibilities
> For the management of a transaction-scoped persistence context, if there is no EntityManager already associated with the JTA transaction:
> * The container creates a new entity manager by calling EntityManagerFactory.createEntityManager when the first invocation of an entity manager with PersistenceContextType.TRANSACTION occurs within the scope of a business method executing in the JTA transaction.
> * After the JTA transaction has completed (either by transaction commit or rollback), the container closes the entity manager by calling EntityManager.close. [88] Note that the JTA transaction may rollback in a background thread (e.g., as a result of transaction timeout), in which case the container should arrange for the entity manager to be closed but the EntityManager.close method should not be concurrently invoked while the application is in an EntityManager invocation.
> The container must throw the TransactionRequiredException if a transaction-scoped persistence context is used and the EntityManager persist, remove, merge, or refresh method is invoked when no transaction is active.
> For stateful session beans with extended persistence contexts:
> * The container creates an entity manager by calling EntityManagerFactory.createEntityManager when a stateful session bean is created that declares a dependency on an entity manager with PersistenceContextType.EXTENDED. (See section 7.6.3).
> * The container closes the entity manager by calling EntityManager.close after the stateful session bean and all other stateful session beans that have inherited the same persistence context as the entity manager have been removed.
> * When a business method of the stateful session bean is invoked, if the stateful session bean uses container managed transaction demarcation, and the entity manager is not already associated with the current JTA transaction, the container associates the entity manager with the current JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction. If there is a different persistence context already associated with the JTA transaction, the container throws the EJBException.
> * When a business method of the stateful session bean is invoked, if the stateful session bean uses bean managed transaction demarcation and a UserTransaction is begun within the method, the container associates the persistence context with the JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction.
> The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.
> [87] It is not required that these contracts be used when a third-party persistence provider is not used: the container might use these same APIs or its might use its own internal APIs.
> [88] The container may choose to pool EntityManagers: it instead of creating and closing in each case, it may acquire one from its pool and call clear() on it.
> {quote}
> One challenge with introducing an entity manager (per EntityManagerFactory) cache, is knowing when to close EntityManagers after certain errors have occurred on the EntityManager:
> * In [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], we can try to retrieve an entity manager from the cache (cache reference can be passed into the TransactionScopedEntityManager proxy constructor), if cache is empty, then create a new entity manager to return.
> * In https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav..., if caching is enabled, we should call EntityManager.clear(), instead of EntityManager.close(), however, if an exception is thrown (on call to em.clear()), the entity manager shouldn't be put in the cache, instead we can try to close it and log/ignore any further exception thrown by the call to em.close().
> * If an entity manager is in a bad state, we shouldn't place it back in the cache. This may really be the same as the previous bullet but I wanted to mention it as a separate bullet, since we may need to add more error checking for the persistence throwing exceptions in [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...] or/and other places.
> * In [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], if caching is enabled, we should call EntityManager.clear() instead of EntityManager.close(), however, if an exception is thrown (on call to em.clear()), the entity manager shouldn't be put in the cache, instead we can try to close it and log/ignore any any further exception thrown by the call to em.close().
> * Lastly, we should update [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], to deal with releasing the entity manager cache before calling entityManagerFactory.close(). Since, [https://docs.oracle.com/javaee/7/api/javax/persistence/EntityManagerFacto...] says that the entity managers will be closed automatically, we probably can just clear the cache of EntityManagers, instead of actually calling EntityManager.close() on each one in the cache.
> Also, the reference to the cache of EntityManagers, will be invoked by multiple (concurrent) threads and such, the cache storage should be written to be thread safe.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
- 1
- 0
[JBoss JIRA] (DROOLS-3110) [DMN Designer] Unable to deploy model with custom data type
by Guilherme Carreiro (Jira)
[ https://issues.jboss.org/browse/DROOLS-3110?page=com.atlassian.jira.plugi... ]
Guilherme Carreiro reassigned DROOLS-3110:
------------------------------------------
Assignee: Daniel José dos Santos (was: Guilherme Carreiro)
> [DMN Designer] Unable to deploy model with custom data type
> -----------------------------------------------------------
>
> Key: DROOLS-3110
> URL: https://issues.jboss.org/browse/DROOLS-3110
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.13.0.Final
> Reporter: Jozef Marko
> Assignee: Daniel José dos Santos
> Priority: Blocker
> Labels: drools-tools
> Attachments: a1.dmn, a2.dmn, error.log
>
>
> I created the [^a1.dmn] model using features of DROOLS-3024, however then I am not able to deploy the created dmn model, the attached [^error.log] appears in server log.
> h2. Another steps to reproduce
> Run the code snippet below
> {code:java}
> final DMNRuntime runtime = DMNRuntimeUtil.createRuntime("a2.dmn", this.getClass() );
> final DMNModel dmnModel = runtime.getModel("https://github.com/kiegroup/drools/kie-dmn", "a2" );
> assertThat( DMNRuntimeUtil.formatMessages( dmnModel.getMessages() ), dmnModel.hasErrors(), is( false ) );
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
- 1
- 0
[JBoss JIRA] (DROOLS-3038) [DMN Designer] Added type can not be resolved
by Guilherme Carreiro (Jira)
[ https://issues.jboss.org/browse/DROOLS-3038?page=com.atlassian.jira.plugi... ]
Guilherme Carreiro reassigned DROOLS-3038:
------------------------------------------
Assignee: Daniel José dos Santos (was: Guilherme Carreiro)
> [DMN Designer] Added type can not be resolved
> ---------------------------------------------
>
> Key: DROOLS-3038
> URL: https://issues.jboss.org/browse/DROOLS-3038
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.12.0.Final
> Reporter: Jozef Marko
> Assignee: Daniel José dos Santos
> Priority: Blocker
> Labels: drools-tools
> Attachments: DROOLS-3038.dmn, Screenshot from 2018-09-26 12-57-20.png, Screenshot from 2018-09-26 12-58-02.png, Screenshot from 2018-09-26 12-58-12.png
>
>
> {{12:53:34,884 ERROR [org.kie.dmn.core.compiler.DMNCompilerImpl] (EJB default - 3) Unable to resolve type reference 'tNum' on node 'Decision-1'}} is error shown to user after reopening DMN model with used new defined item definition.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
- 1
- 0
[JBoss JIRA] (WFLY-11233) allow EntityManager caching in the JPA container
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-11233?page=com.atlassian.jira.plugin... ]
Scott Marlow updated WFLY-11233:
--------------------------------
Description:
It could be interesting to see if caching EntityManager instances (per EntityManagerFactory) could improve performance for applications, that could benefit from that.
The JPA 2.2 specification mentions the below, pay particular attention to the text "whether entity manager instances are sometimes reused" in section 7.8.2, also look at mention of [88]:
{quote}
7.8 Requirements on the Container
7.8.1 Application-managed Persistence Contexts
When application-managed persistence contexts are used, the container must instantiate the entity manager factory and expose it to the application via JNDI. The container might use internal APIs to create the entity manager factory, or it might use the PersistenceProvider.createContainerEntityManagerFactory method. However, the container is required to support third-party persistence providers, and in this case the container must use the PersistenceProvider.createContainerEntityManagerFactory method to create the entity manager factory and the EntityManagerFactory.close method to destroy the entity manager factory prior to shutdown (if it has not been previously closed by the application).
7.8.2 Container Managed Persistence Contexts
The container is responsible for managing the lifecycle of container-managed persistence contexts, for injecting EntityManager references into web components and session bean and message-driven bean components, and for making EntityManager references available to direct lookups in JNDI. When operating with a third-party persistence provider, the container uses the contracts defined in section 7.9 to create and destroy container-managed persistence contexts. It is undefined whether a new entity manager instance is created for every persistence context, or whether entity manager instances are sometimes reused. Exactly how the container maintains the association between persistence context and JTA transaction is not defined. If a persistence context is already associated with a JTA transaction, the container uses that persistence context for subsequent invocations within the scope of that transaction, according to the semantics for persistence context propagation defined in section 7.6.4.
7.9 Runtime Contracts between the Container and Persistence Provider
This section describes contracts between the container and the persistence provider for the pluggability of third-party persistence providers. Containers are required to support these pluggability contracts. [87]
7.9.1 Container Responsibilities
For the management of a transaction-scoped persistence context, if there is no EntityManager already associated with the JTA transaction:
* The container creates a new entity manager by calling EntityManagerFactory.createEntityManager when the first invocation of an entity manager with PersistenceContextType.TRANSACTION occurs within the scope of a business method executing in the JTA transaction.
* After the JTA transaction has completed (either by transaction commit or rollback), the container closes the entity manager by calling EntityManager.close. [88] Note that the JTA transaction may rollback in a background thread (e.g., as a result of transaction timeout), in which case the container should arrange for the entity manager to be closed but the EntityManager.close method should not be concurrently invoked while the application is in an EntityManager invocation.
The container must throw the TransactionRequiredException if a transaction-scoped persistence context is used and the EntityManager persist, remove, merge, or refresh method is invoked when no transaction is active.
For stateful session beans with extended persistence contexts:
* The container creates an entity manager by calling EntityManagerFactory.createEntityManager when a stateful session bean is created that declares a dependency on an entity manager with PersistenceContextType.EXTENDED. (See section 7.6.3).
* The container closes the entity manager by calling EntityManager.close after the stateful session bean and all other stateful session beans that have inherited the same persistence context as the entity manager have been removed.
* When a business method of the stateful session bean is invoked, if the stateful session bean uses container managed transaction demarcation, and the entity manager is not already associated with the current JTA transaction, the container associates the entity manager with the current JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction. If there is a different persistence context already associated with the JTA transaction, the container throws the EJBException.
* When a business method of the stateful session bean is invoked, if the stateful session bean uses bean managed transaction demarcation and a UserTransaction is begun within the method, the container associates the persistence context with the JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction.
The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.
[87] It is not required that these contracts be used when a third-party persistence provider is not used: the container might use these same APIs or its might use its own internal APIs.
[88] The container may choose to pool EntityManagers: it instead of creating and closing in each case, it may acquire one from its pool and call clear() on it.
{quote}
One challenge with introducing an entity manager (per EntityManagerFactory) cache, is knowing when to close EntityManagers after certain errors have occurred on the EntityManager:
* In https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav..., if caching is enabled, we should call EntityManager.clear(), instead of EntityManager.close(), however, if an exception is thrown (on call to em.clear()), the entity manager shouldn't be put in the cache, instead we can try to close it and log/ignore any further exception thrown by the call to em.close().
* If an entity manager is in a bad state, we shouldn't place it back in the cache. This may really be the same as the previous bullet but I wanted to mention it as a separate bullet, since we may need to add more error checking for the persistence throwing exceptions in [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...] or/and other places.
* In [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], if caching is enabled, we should call EntityManager.clear() instead of EntityManager.close(), however, if an exception is thrown (on call to em.clear()), the entity manager shouldn't be put in the cache, instead we can try to close it and log/ignore any any further exception thrown by the call to em.close().
* Lastly, we should update [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], to deal with releasing the entity manager cache before calling entityManagerFactory.close(). Since, [https://docs.oracle.com/javaee/7/api/javax/persistence/EntityManagerFacto...] says that the entity managers will be closed automatically, we probably can just clear the cache of EntityManagers, instead of actually calling EntityManager.close() on each one in the cache.
Also, the reference to the cache of EntityManagers, will be invoked by multiple (concurrent) threads and such, the cache storage should be written to be thread safe.
was:
It could be interesting to see if caching EntityManager instances (per EntityManagerFactory) could improve performance for applications, that could benefit from that.
The JPA 2.2 specification mentions the below, pay particular attention to the text "whether entity manager instances are sometimes reused" in section 7.8.2, also look at mention of [88]:
{quote}
7.8 Requirements on the Container
7.8.1 Application-managed Persistence Contexts
When application-managed persistence contexts are used, the container must instantiate the entity manager factory and expose it to the application via JNDI. The container might use internal APIs to create the entity manager factory, or it might use the PersistenceProvider.createContainerEntityManagerFactory method. However, the container is required to support third-party persistence providers, and in this case the container must use the PersistenceProvider.createContainerEntityManagerFactory method to create the entity manager factory and the EntityManagerFactory.close method to destroy the entity manager factory prior to shutdown (if it has not been previously closed by the application).
7.8.2 Container Managed Persistence Contexts
The container is responsible for managing the lifecycle of container-managed persistence contexts, for injecting EntityManager references into web components and session bean and message-driven bean components, and for making EntityManager references available to direct lookups in JNDI. When operating with a third-party persistence provider, the container uses the contracts defined in section 7.9 to create and destroy container-managed persistence contexts. It is undefined whether a new entity manager instance is created for every persistence context, or whether entity manager instances are sometimes reused. Exactly how the container maintains the association between persistence context and JTA transaction is not defined. If a persistence context is already associated with a JTA transaction, the container uses that persistence context for subsequent invocations within the scope of that transaction, according to the semantics for persistence context propagation defined in section 7.6.4.
7.9 Runtime Contracts between the Container and Persistence Provider
This section describes contracts between the container and the persistence provider for the pluggability of third-party persistence providers. Containers are required to support these pluggability contracts. [87]
7.9.1 Container Responsibilities
For the management of a transaction-scoped persistence context, if there is no EntityManager already associated with the JTA transaction:
* The container creates a new entity manager by calling EntityManagerFactory.createEntityManager when the first invocation of an entity manager with PersistenceContextType.TRANSACTION occurs within the scope of a business method executing in the JTA transaction.
* After the JTA transaction has completed (either by transaction commit or rollback), the container closes the entity manager by calling EntityManager.close. [88] Note that the JTA transaction may rollback in a background thread (e.g., as a result of transaction timeout), in which case the container should arrange for the entity manager to be closed but the EntityManager.close method should not be concurrently invoked while the application is in an EntityManager invocation.
The container must throw the TransactionRequiredException if a transaction-scoped persistence context is used and the EntityManager persist, remove, merge, or refresh method is invoked when no transaction is active.
For stateful session beans with extended persistence contexts:
* The container creates an entity manager by calling EntityManagerFactory.createEntityManager when a stateful session bean is created that declares a dependency on an entity manager with PersistenceContextType.EXTENDED. (See section 7.6.3).
* The container closes the entity manager by calling EntityManager.close after the stateful session bean and all other stateful session beans that have inherited the same persistence context as the entity manager have been removed.
* When a business method of the stateful session bean is invoked, if the stateful session bean uses container managed transaction demarcation, and the entity manager is not already associated with the current JTA transaction, the container associates the entity manager with the current JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction. If there is a different persistence context already associated with the JTA transaction, the container throws the EJBException.
* When a business method of the stateful session bean is invoked, if the stateful session bean uses bean managed transaction demarcation and a UserTransaction is begun within the method, the container associates the persistence context with the JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction.
The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.
[87] It is not required that these contracts be used when a third-party persistence provider is not used: the container might use these same APIs or its might use its own internal APIs.
[88] The container may choose to pool EntityManagers: it instead of creating and closing in each case, it may acquire one from its pool and call clear() on it.
{quote}
One challenge with introducing an entity manager (per EntityManagerFactory) cache, is knowing when to close EntityManagers after certain errors have occurred on the EntityManager:
* In https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav..., if caching is enabled, we should call EntityManager.clear(), instead of EntityManager.close(), however, if an exception is thrown (on call to em.clear()), the entity manager shouldn't be put in the cache, instead we can try to close it and log/ignore any further exception thrown by the call to em.close().
* If an entity manager is in a bad state, we shouldn't place it back in the cache. This may really be the same as the previous bullet but I wanted to mention it as a separate bullet, since we may need to add more error checking for the persistence throwing exceptions in [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...] or/and other places.
* In [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], if caching is enabled, we should call EntityManager.clear() instead of EntityManager.close(), however, if an exception is thrown (on call to em.clear()), the entity manager shouldn't be put in the cache, instead we can try to close it and log/ignore any any further exception thrown by the call to em.close().
> allow EntityManager caching in the JPA container
> ------------------------------------------------
>
> Key: WFLY-11233
> URL: https://issues.jboss.org/browse/WFLY-11233
> Project: WildFly
> Issue Type: Enhancement
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Priority: Major
>
> It could be interesting to see if caching EntityManager instances (per EntityManagerFactory) could improve performance for applications, that could benefit from that.
> The JPA 2.2 specification mentions the below, pay particular attention to the text "whether entity manager instances are sometimes reused" in section 7.8.2, also look at mention of [88]:
> {quote}
> 7.8 Requirements on the Container
> 7.8.1 Application-managed Persistence Contexts
> When application-managed persistence contexts are used, the container must instantiate the entity manager factory and expose it to the application via JNDI. The container might use internal APIs to create the entity manager factory, or it might use the PersistenceProvider.createContainerEntityManagerFactory method. However, the container is required to support third-party persistence providers, and in this case the container must use the PersistenceProvider.createContainerEntityManagerFactory method to create the entity manager factory and the EntityManagerFactory.close method to destroy the entity manager factory prior to shutdown (if it has not been previously closed by the application).
> 7.8.2 Container Managed Persistence Contexts
> The container is responsible for managing the lifecycle of container-managed persistence contexts, for injecting EntityManager references into web components and session bean and message-driven bean components, and for making EntityManager references available to direct lookups in JNDI. When operating with a third-party persistence provider, the container uses the contracts defined in section 7.9 to create and destroy container-managed persistence contexts. It is undefined whether a new entity manager instance is created for every persistence context, or whether entity manager instances are sometimes reused. Exactly how the container maintains the association between persistence context and JTA transaction is not defined. If a persistence context is already associated with a JTA transaction, the container uses that persistence context for subsequent invocations within the scope of that transaction, according to the semantics for persistence context propagation defined in section 7.6.4.
> 7.9 Runtime Contracts between the Container and Persistence Provider
> This section describes contracts between the container and the persistence provider for the pluggability of third-party persistence providers. Containers are required to support these pluggability contracts. [87]
> 7.9.1 Container Responsibilities
> For the management of a transaction-scoped persistence context, if there is no EntityManager already associated with the JTA transaction:
> * The container creates a new entity manager by calling EntityManagerFactory.createEntityManager when the first invocation of an entity manager with PersistenceContextType.TRANSACTION occurs within the scope of a business method executing in the JTA transaction.
> * After the JTA transaction has completed (either by transaction commit or rollback), the container closes the entity manager by calling EntityManager.close. [88] Note that the JTA transaction may rollback in a background thread (e.g., as a result of transaction timeout), in which case the container should arrange for the entity manager to be closed but the EntityManager.close method should not be concurrently invoked while the application is in an EntityManager invocation.
> The container must throw the TransactionRequiredException if a transaction-scoped persistence context is used and the EntityManager persist, remove, merge, or refresh method is invoked when no transaction is active.
> For stateful session beans with extended persistence contexts:
> * The container creates an entity manager by calling EntityManagerFactory.createEntityManager when a stateful session bean is created that declares a dependency on an entity manager with PersistenceContextType.EXTENDED. (See section 7.6.3).
> * The container closes the entity manager by calling EntityManager.close after the stateful session bean and all other stateful session beans that have inherited the same persistence context as the entity manager have been removed.
> * When a business method of the stateful session bean is invoked, if the stateful session bean uses container managed transaction demarcation, and the entity manager is not already associated with the current JTA transaction, the container associates the entity manager with the current JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction. If there is a different persistence context already associated with the JTA transaction, the container throws the EJBException.
> * When a business method of the stateful session bean is invoked, if the stateful session bean uses bean managed transaction demarcation and a UserTransaction is begun within the method, the container associates the persistence context with the JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction.
> The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.
> [87] It is not required that these contracts be used when a third-party persistence provider is not used: the container might use these same APIs or its might use its own internal APIs.
> [88] The container may choose to pool EntityManagers: it instead of creating and closing in each case, it may acquire one from its pool and call clear() on it.
> {quote}
> One challenge with introducing an entity manager (per EntityManagerFactory) cache, is knowing when to close EntityManagers after certain errors have occurred on the EntityManager:
> * In https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav..., if caching is enabled, we should call EntityManager.clear(), instead of EntityManager.close(), however, if an exception is thrown (on call to em.clear()), the entity manager shouldn't be put in the cache, instead we can try to close it and log/ignore any further exception thrown by the call to em.close().
> * If an entity manager is in a bad state, we shouldn't place it back in the cache. This may really be the same as the previous bullet but I wanted to mention it as a separate bullet, since we may need to add more error checking for the persistence throwing exceptions in [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...] or/and other places.
> * In [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], if caching is enabled, we should call EntityManager.clear() instead of EntityManager.close(), however, if an exception is thrown (on call to em.clear()), the entity manager shouldn't be put in the cache, instead we can try to close it and log/ignore any any further exception thrown by the call to em.close().
> * Lastly, we should update [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], to deal with releasing the entity manager cache before calling entityManagerFactory.close(). Since, [https://docs.oracle.com/javaee/7/api/javax/persistence/EntityManagerFacto...] says that the entity managers will be closed automatically, we probably can just clear the cache of EntityManagers, instead of actually calling EntityManager.close() on each one in the cache.
> Also, the reference to the cache of EntityManagers, will be invoked by multiple (concurrent) threads and such, the cache storage should be written to be thread safe.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
- 1
- 0
[JBoss JIRA] (DROOLS-3156) Explore using a full screen view instead of a dialog.
by Liz Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-3156?page=com.atlassian.jira.plugi... ]
Liz Clayton commented on DROOLS-3156:
-------------------------------------
[~manstis] Thanks, yes need to figure that out. Ideally, do constraints need to be defined kind of inline when the user selects the type? Or is it something that they bake in to the Type definition via the "Manage" list options.
> Explore using a full screen view instead of a dialog.
> ------------------------------------------------------
>
> Key: DROOLS-3156
> URL: https://issues.jboss.org/browse/DROOLS-3156
> Project: Drools
> Issue Type: Sub-task
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Priority: Major
> Attachments: Move.png, full-screen.png
>
>
> * Porting the list in the dialog view to a full screen would better support editing Advanced options such as Data type restrictions.
> * A lot of other editors have a "Data Object" tab (to import classes from other packages); so DMN having a "Data Types" tab would offer some degree of consistency.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
- 1
- 0
[JBoss JIRA] (WFLY-11233) allow EntityManager caching in the JPA container
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-11233?page=com.atlassian.jira.plugin... ]
Scott Marlow updated WFLY-11233:
--------------------------------
Description:
It could be interesting to see if caching EntityManager instances (per EntityManagerFactory) could improve performance for applications, that could benefit from that.
The JPA 2.2 specification mentions the below, pay particular attention to the text "whether entity manager instances are sometimes reused" in section 7.8.2, also look at mention of [88]:
{quote}
7.8 Requirements on the Container
7.8.1 Application-managed Persistence Contexts
When application-managed persistence contexts are used, the container must instantiate the entity manager factory and expose it to the application via JNDI. The container might use internal APIs to create the entity manager factory, or it might use the PersistenceProvider.createContainerEntityManagerFactory method. However, the container is required to support third-party persistence providers, and in this case the container must use the PersistenceProvider.createContainerEntityManagerFactory method to create the entity manager factory and the EntityManagerFactory.close method to destroy the entity manager factory prior to shutdown (if it has not been previously closed by the application).
7.8.2 Container Managed Persistence Contexts
The container is responsible for managing the lifecycle of container-managed persistence contexts, for injecting EntityManager references into web components and session bean and message-driven bean components, and for making EntityManager references available to direct lookups in JNDI. When operating with a third-party persistence provider, the container uses the contracts defined in section 7.9 to create and destroy container-managed persistence contexts. It is undefined whether a new entity manager instance is created for every persistence context, or whether entity manager instances are sometimes reused. Exactly how the container maintains the association between persistence context and JTA transaction is not defined. If a persistence context is already associated with a JTA transaction, the container uses that persistence context for subsequent invocations within the scope of that transaction, according to the semantics for persistence context propagation defined in section 7.6.4.
7.9 Runtime Contracts between the Container and Persistence Provider
This section describes contracts between the container and the persistence provider for the pluggability of third-party persistence providers. Containers are required to support these pluggability contracts. [87]
7.9.1 Container Responsibilities
For the management of a transaction-scoped persistence context, if there is no EntityManager already associated with the JTA transaction:
* The container creates a new entity manager by calling EntityManagerFactory.createEntityManager when the first invocation of an entity manager with PersistenceContextType.TRANSACTION occurs within the scope of a business method executing in the JTA transaction.
* After the JTA transaction has completed (either by transaction commit or rollback), the container closes the entity manager by calling EntityManager.close. [88] Note that the JTA transaction may rollback in a background thread (e.g., as a result of transaction timeout), in which case the container should arrange for the entity manager to be closed but the EntityManager.close method should not be concurrently invoked while the application is in an EntityManager invocation.
The container must throw the TransactionRequiredException if a transaction-scoped persistence context is used and the EntityManager persist, remove, merge, or refresh method is invoked when no transaction is active.
For stateful session beans with extended persistence contexts:
* The container creates an entity manager by calling EntityManagerFactory.createEntityManager when a stateful session bean is created that declares a dependency on an entity manager with PersistenceContextType.EXTENDED. (See section 7.6.3).
* The container closes the entity manager by calling EntityManager.close after the stateful session bean and all other stateful session beans that have inherited the same persistence context as the entity manager have been removed.
* When a business method of the stateful session bean is invoked, if the stateful session bean uses container managed transaction demarcation, and the entity manager is not already associated with the current JTA transaction, the container associates the entity manager with the current JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction. If there is a different persistence context already associated with the JTA transaction, the container throws the EJBException.
* When a business method of the stateful session bean is invoked, if the stateful session bean uses bean managed transaction demarcation and a UserTransaction is begun within the method, the container associates the persistence context with the JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction.
The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.
[87] It is not required that these contracts be used when a third-party persistence provider is not used: the container might use these same APIs or its might use its own internal APIs.
[88] The container may choose to pool EntityManagers: it instead of creating and closing in each case, it may acquire one from its pool and call clear() on it.
{quote}
One challenge with introducing an entity manager (per EntityManagerFactory) cache, is knowing when to close EntityManagers after certain errors have occurred on the EntityManager:
* In https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav..., if caching is enabled, we should call EntityManager.clear(), instead of EntityManager.close(), however, if an exception is thrown (on call to em.clear()), the entity manager shouldn't be put in the cache, instead we can try to close it and log/ignore any further exception thrown by the call to em.close().
* If an entity manager is in a bad state, we shouldn't place it back in the cache. This may really be the same as the previous bullet but I wanted to mention it as a separate bullet, since we may need to add more error checking for the persistence throwing exceptions in [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...] or/and other places.
* In [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], if caching is enabled, we should call EntityManager.clear() instead of EntityManager.close(), however, if an exception is thrown (on call to em.clear()), the entity manager shouldn't be put in the cache, instead we can try to close it and log/ignore any any further exception thrown by the call to em.close().
was:
It could be interesting to see if caching EntityManager instances (per EntityManagerFactory) could improve performance for applications, that could benefit from that.
The JPA 2.2 specification mentions the below, pay particular attention to the text "whether entity manager instances are sometimes reused" in section 7.8.2:
{quote}
7.8 Requirements on the Container
7.8.1 Application-managed Persistence Contexts
When application-managed persistence contexts are used, the container must instantiate the entity manager factory and expose it to the application via JNDI. The container might use internal APIs to create the entity manager factory, or it might use the PersistenceProvider.createContainerEntityManagerFactory method. However, the container is required to support third-party persistence providers, and in this case the container must use the PersistenceProvider.createContainerEntityManagerFactory method to create the entity manager factory and the EntityManagerFactory.close method to destroy the entity manager factory prior to shutdown (if it has not been previously closed by the application).
7.8.2 Container Managed Persistence Contexts
The container is responsible for managing the lifecycle of container-managed persistence contexts, for injecting EntityManager references into web components and session bean and message-driven bean components, and for making EntityManager references available to direct lookups in JNDI. When operating with a third-party persistence provider, the container uses the contracts defined in section 7.9 to create and destroy container-managed persistence contexts. It is undefined whether a new entity manager instance is created for every persistence context, or whether entity manager instances are sometimes reused. Exactly how the container maintains the association between persistence context and JTA transaction is not defined. If a persistence context is already associated with a JTA transaction, the container uses that persistence context for subsequent invocations within the scope of that transaction, according to the semantics for persistence context propagation defined in section 7.6.4.
7.9 Runtime Contracts between the Container and Persistence Provider
This section describes contracts between the container and the persistence provider for the pluggability of third-party persistence providers. Containers are required to support these pluggability contracts. [87]
7.9.1 Container Responsibilities
For the management of a transaction-scoped persistence context, if there is no EntityManager already associated with the JTA transaction:
* The container creates a new entity manager by calling EntityManagerFactory.createEntityManager when the first invocation of an entity manager with PersistenceContextType.TRANSACTION occurs within the scope of a business method executing in the JTA transaction.
* After the JTA transaction has completed (either by transaction commit or rollback), the container closes the entity manager by calling EntityManager.close. [88] Note that the JTA transaction may rollback in a background thread (e.g., as a result of transaction timeout), in which case the container should arrange for the entity manager to be closed but the EntityManager.close method should not be concurrently invoked while the application is in an EntityManager invocation.
The container must throw the TransactionRequiredException if a transaction-scoped persistence context is used and the EntityManager persist, remove, merge, or refresh method is invoked when no transaction is active.
For stateful session beans with extended persistence contexts:
* The container creates an entity manager by calling EntityManagerFactory.createEntityManager when a stateful session bean is created that declares a dependency on an entity manager with PersistenceContextType.EXTENDED. (See section 7.6.3).
> allow EntityManager caching in the JPA container
> ------------------------------------------------
>
> Key: WFLY-11233
> URL: https://issues.jboss.org/browse/WFLY-11233
> Project: WildFly
> Issue Type: Enhancement
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Priority: Major
>
> It could be interesting to see if caching EntityManager instances (per EntityManagerFactory) could improve performance for applications, that could benefit from that.
> The JPA 2.2 specification mentions the below, pay particular attention to the text "whether entity manager instances are sometimes reused" in section 7.8.2, also look at mention of [88]:
> {quote}
> 7.8 Requirements on the Container
> 7.8.1 Application-managed Persistence Contexts
> When application-managed persistence contexts are used, the container must instantiate the entity manager factory and expose it to the application via JNDI. The container might use internal APIs to create the entity manager factory, or it might use the PersistenceProvider.createContainerEntityManagerFactory method. However, the container is required to support third-party persistence providers, and in this case the container must use the PersistenceProvider.createContainerEntityManagerFactory method to create the entity manager factory and the EntityManagerFactory.close method to destroy the entity manager factory prior to shutdown (if it has not been previously closed by the application).
> 7.8.2 Container Managed Persistence Contexts
> The container is responsible for managing the lifecycle of container-managed persistence contexts, for injecting EntityManager references into web components and session bean and message-driven bean components, and for making EntityManager references available to direct lookups in JNDI. When operating with a third-party persistence provider, the container uses the contracts defined in section 7.9 to create and destroy container-managed persistence contexts. It is undefined whether a new entity manager instance is created for every persistence context, or whether entity manager instances are sometimes reused. Exactly how the container maintains the association between persistence context and JTA transaction is not defined. If a persistence context is already associated with a JTA transaction, the container uses that persistence context for subsequent invocations within the scope of that transaction, according to the semantics for persistence context propagation defined in section 7.6.4.
> 7.9 Runtime Contracts between the Container and Persistence Provider
> This section describes contracts between the container and the persistence provider for the pluggability of third-party persistence providers. Containers are required to support these pluggability contracts. [87]
> 7.9.1 Container Responsibilities
> For the management of a transaction-scoped persistence context, if there is no EntityManager already associated with the JTA transaction:
> * The container creates a new entity manager by calling EntityManagerFactory.createEntityManager when the first invocation of an entity manager with PersistenceContextType.TRANSACTION occurs within the scope of a business method executing in the JTA transaction.
> * After the JTA transaction has completed (either by transaction commit or rollback), the container closes the entity manager by calling EntityManager.close. [88] Note that the JTA transaction may rollback in a background thread (e.g., as a result of transaction timeout), in which case the container should arrange for the entity manager to be closed but the EntityManager.close method should not be concurrently invoked while the application is in an EntityManager invocation.
> The container must throw the TransactionRequiredException if a transaction-scoped persistence context is used and the EntityManager persist, remove, merge, or refresh method is invoked when no transaction is active.
> For stateful session beans with extended persistence contexts:
> * The container creates an entity manager by calling EntityManagerFactory.createEntityManager when a stateful session bean is created that declares a dependency on an entity manager with PersistenceContextType.EXTENDED. (See section 7.6.3).
> * The container closes the entity manager by calling EntityManager.close after the stateful session bean and all other stateful session beans that have inherited the same persistence context as the entity manager have been removed.
> * When a business method of the stateful session bean is invoked, if the stateful session bean uses container managed transaction demarcation, and the entity manager is not already associated with the current JTA transaction, the container associates the entity manager with the current JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction. If there is a different persistence context already associated with the JTA transaction, the container throws the EJBException.
> * When a business method of the stateful session bean is invoked, if the stateful session bean uses bean managed transaction demarcation and a UserTransaction is begun within the method, the container associates the persistence context with the JTA transaction and, if the persistence context is of type SynchronizationType.SYNCHRONIZED, the container calls EntityManager.joinTransaction.
> The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.
> [87] It is not required that these contracts be used when a third-party persistence provider is not used: the container might use these same APIs or its might use its own internal APIs.
> [88] The container may choose to pool EntityManagers: it instead of creating and closing in each case, it may acquire one from its pool and call clear() on it.
> {quote}
> One challenge with introducing an entity manager (per EntityManagerFactory) cache, is knowing when to close EntityManagers after certain errors have occurred on the EntityManager:
> * In https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav..., if caching is enabled, we should call EntityManager.clear(), instead of EntityManager.close(), however, if an exception is thrown (on call to em.clear()), the entity manager shouldn't be put in the cache, instead we can try to close it and log/ignore any further exception thrown by the call to em.close().
> * If an entity manager is in a bad state, we shouldn't place it back in the cache. This may really be the same as the previous bullet but I wanted to mention it as a separate bullet, since we may need to add more error checking for the persistence throwing exceptions in [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...] or/and other places.
> * In [https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/jav...], if caching is enabled, we should call EntityManager.clear() instead of EntityManager.close(), however, if an exception is thrown (on call to em.clear()), the entity manager shouldn't be put in the cache, instead we can try to close it and log/ignore any any further exception thrown by the call to em.close().
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
- 1
- 0