The JPA connector acquires several EntityManager instances, but does not close all of them. This can cause a memory leak in the code, and can cause the JVM to run out of memory. Because the EntityManager is the manager for all of the JPA entity beans (obviously), not closing them will retain objects in memory and prevent them from being garbage collected.

There doesn't appear to be an easy way with the current JpaSource and JpaConnection design to properly do this, other than call the JpaSource.close() method. Unfortunately that does not always work, as the current implementation of JpaSource.getConnection() may (if the model is changed) create a new EntityManagerFactory. And even if the JpaConnection did close the EntityManager it's using, the JpaSource's EntityManagerFactory is not guaranteed to be called (even if we adopt a new RepositorySource.close() and require it to be called everywhere).

The best way to fix this might be for the JpaSource to not have to maintain all this state (like it currently does), but instead to have an object in-between the JpaSource and JpaConnection that maintains the EntityManagerFactory and creates EntityManagers as needed. The JpaSource can hold onto this, but wouldn't own the instances. This intermediate object can always ensure that all EntityManagers and EntityManagerFactories are closed when no longer needed (e.g., using reference counts and a "last-one-to-leave-turn-the-lights-off" approach). JpaConnection.close() would obvious signal to this object that it no longer needs its EntityManager.

JpaSource cannot properly do all this management, because its bean properties can be changed at any time, meaning that even after some connections to one database have been created, the JpaSource can be changed and pointed to a different database. Yes, this isn't good practice, but it technically is possible and thus needs to be addressed.