f.haeder.net

JPA causes tons of SQL queries

I'm currently developing (free time project) a Java Server Faces application which uses the #JPA (very common to do so) over EJBs (Enterprise Java Beans). When I turned on logging of SQL queries, I thought I didn't see it right. For each entity ("row" in database table) a distinct query has been issued. Means, when I have 1,000 rows, the same amount of queries are being issued.

This can become a nightmare when "only" 100 users are on the server. Does someone know how to reconfigure the JPA (I use #Payara ) to issue only one SQL query per table?

Surely I have used JPQL (Java Persistence Query Language) and no WHERE was used there. So normally the whole table should be fetched. But this is not the case for linked tables (e.g. with @OneToOne) where each such referenced entity is being fetched distinctly.

So is there a way to prevent this from happening? RAM is not a issue here. 16 GB are installed and data will not grow so much.
#JPA #Payara jpa performance sql tweaks
Limit the amount of fetched rows with pagination for example?
Maybe I need to explain more about my program. On initialization of the backing bean (means when an instance is being created and the web container is creating a wrapper class around it) I load the entire table rows from the EJB to into the controller to cache it there (see #JCache #JS107 ).

This gives great performance improvement due to not with every request (POST/GET) data is not being loaded from database but taken from cache. This is what I call asynchronous loading of data, most PHP applications however are synchronous, means with every click data is fetched from database and scripts are loaded and parsed (OpCache is maybe a bit improving here) and are being "forgotten" after the request was finished.

But with a JSF application, the "controller" (backing bean) remains instanced (and wrapped) in the web container's heap until you redeploy the application or restart the web container.

So sure I want to use that advantage of having all loaded at "all" (not at the beginning, but you can implement a ServletContextListener interface where you can "hook" on the initialization phase) times. Still this issue is there.

As you can see, not on every request these SQL queries are performed (which is very good for overall performance) but still they are really a lot. Just imagine 1,000 users on your web server (you may need a cluster then) and several 10,000 records.

Sure, when you cache them all in RAM, then you need a lot RAM. The #Payara application server uses here #Hazelcast ( https://hazelcast.com/ ) for having a distributed heap (cluster members contribute their heap to the cluster) and JCache (JSR107).

So what now? I still found this a bit to much. Currently I use eager fetch-mode, I could switch to lazy but that only delays the problem as foreign entities are being lazyless (on getter invocation) loaded.
#JSR107 is the right one ...
So limiting the amount of fetched rows by pagination is only working with synchronous applications where on each request, the database is being queried. This is not the case with asynchronous applications where the whole data is already loaded (and cached) and SELECT statements are (normally) reduced to a minimum.
I think you have the terminology backwards. In PHP-Javascript web applications asynchronous means the data is fetched when it is needed, after the main page is loaded. This gave the term AJAX ("Asynchronous JavaScript + XML"). On the contrary, synchronous would mean the data is loaded on page load. For example, on Friendica, the network page is loaded synchronously, but then the post refresh or the infinite scroll are loaded asynchronously. I don't think it matters for your problem, but it may confuse other people.

Back to your issue. Initial data load takes more RAM. This actually was the subject of a recent performance improvement in Friendica: should we load all the configuration values at once at the start of each script or should we query each individual values? it turns out RAM consumption rarely is the bottleneck in a PHP application because of the "fire and forget" architecture you described: the script is loaded, executed, forgotten. So a increase in memory consumption wouldn't be significant, especially if it implies a reduction in script execution because the memory consumption pike will be shorter. However, for a long-running server application, using more RAM probably is a bigger deal.

No matter what, here are the general axes of improvement to reduce the number of requests:
  • Write your own SQL query: I don't know if is it possible, especially in Java where everything seems to be broken down in atomic parts.
  • Limit the initial data load, use lazy loading beyond: Like you said, the initial data load doesn't scale. If you can cap the size of the initial data load, you probably can use a dynamic cache checking for row existence before querying either the cache, or the DB directly.
I understand and know what AJAX means and I'm not targeting PHP or labeling it as bad and "look how cool this or that is". No, that is not my style.

Back to my issue, the #JPA (Java Persistence API) fetches records from database, creates an instance for each record of your entity class and wraps it into a proxy class. Then that proxy class is being compiled and most JPA implementations are caching them (the entity manager does this). This has nothing to do with the application or that it uses AJAX. My main goal is to reduce invocations of EJB business methods as this is "expensive" (a lot code need to be executed).

Just imagine, you can deploy your model classes on an other server or even data center and from your backing bean's perspective you have to change nothing at all as all is encapsulated away for you (most #JavaEE application servers use #CORBA for serializing and deserializing data).

Means on one server (or cluster, doesn't make a difference in Java code) you have your web "controllers" (they are not called controllers, backing beans are the right words for them) and on the other your model classes are running. This means one thing: distributed application load. :-) BTW: Amazon is running on Java Server Faces, when you hit the "order" button, EJBs are being invoked.

Okay, I'm explaining to much off-topic. With "synchronous" I mean with every request (even AJAX requests as they are basically HTTP requests. too) data is being fetched from the database. With "asynchronous" this is not the case. And I mean with this, that data is not being fetched from on each database, but maybe from a cache (that needs to stay updated, of course).
I didn't think you looked down on PHP, I was just reiterating the structure I personally know inside and out, since I don't know Java much.

Anyway, I probably would go the caching way, it seems more in the spirit of Java (adding a middle block between two atomic blocks) than trying to coerce an atomic block into doing a non-atomic task.
Okay. :-) I have found something programmatic (with annotations) for this, but it looks a bit like an overhead when you have +20 entities. What I would prefer is a 3rd fetch type ALL to the existing EAGER and LAZY. That would have to go into JPA specification, of course which made all persistence providers, like #eclipselink , #hibernate, #datanucleus and so on unified as before every provider did it on their way.

This is why I like the JPA, because it is dbms-independent and provider-independent at the same time. No need to worry if your data is stored in a SQLite, MsSQL, Oracle DB or good-old MySQL or even "exotic" database systems like MongoDB.
I’ve always felt that “things”-independent software often ends up being the lowest common denominator between the abstracted products, and that very few actual migrations occur to justify the loss in features. Sure, on paper not having to care about which DBMS is used is great, but this often erases any advantage of choosing a specific DBMS over another, and migration between DBMS is so expensive that the DBMS-independent sofyware will often be used with a single DBMS for the project lifetime.

Have you seen such pattern professionally?
Remember from which times #JPA came: 2006, there was not much #BigData or so. And yes, there are annotations now that will help model your entities. Maybe I take that approach.
Ah, @NamedEntityGraph(s) were the annotations I was looking for.
For PHP, Doctrine is using annotations as well, but I still don’t like it. I believe the foreign relationships should be defined once, in the database schema, and the application should automatically take them into account, in a long-cached manner if it is too expensive to query the schema on each load.
Yes, that is what I mean with synchronous loading, on each load/request all over again, no persisted caching (except when you use memcache/redis but that is not the solution for all scenarios). One thing that could be interesting for non-Java but #PHP people can be the PHP Application server which aims to be a #JavaEE application server written in PHP. There also the application is loaded at all times and entities are cached there, too.
It's foreign to me because I don't see PHP developers suddenly take the Java infrastructure approach without switching to Java altogether, and conversely, don't see Java developers suddenly learn PHP and reproduce the same infrastructure as well.
I have learned both languages. :-) So I can live in both worlds.
If you get the freedom of choosing a technology for a personal project, which one would you naturally lean towards to?
Hard to say as you cannot compare PHP and Java as they are fundamentally different languages. PHP is type-lazy (allows no type at all) and Java is type-safe (unless you do "unsafe casts").

To answer your question, I like both, if that satisfies your question. :-)
My question was more about ease of use and programming fun versus professional obligation.

In case of you downloaded #payara 173 full and you get an ezception and payara doesn't start, you have delete 3 jars starting with microprofile*.

Why I don't like payed support #2

I currently face a #bug in #Payara that doesn't allow TABLE_PER_CLASS and I cannot change the database layout (as then the main program needs to be changed which involves a lot risky work).

I have filled out a bug report ...
https://github.com/payara/Payara/issues/966

... But they don't want to handle it. I guess I'm not alone with this bug. I don't like such "payment model" where paying customers are priotized. I for my projects provide unpriotized support for any one, unpayed and in my free time: My View - Mailer-Project Bug-Tracker
What do you think about such payment models? Good or bad?

2nd submit: better preview before test.
#bug #Payara payara payed support
The case is closed, maybe someone else will pick it up? !java

The class does not have a descriptor, or a descriptor that does not use inheritance or uses a ClassExtractor for inheritance

The mentioned message still comes when you have @Inheritance (strategy = InheritanceType.TABLE_PER_CLASS) in your abstract (not-persisted) with latest version of #Payara / #Glassfish which both contains #EclipseLink by default.

Strange that they did not yet fix it. And unfortunally migrating to e.g. #WilfFly (which uses other #JPA) seems not so easy as you may think.

Currently I have no idea how to fix it and sadly I need the strategy as this #JavaEE application is written for an existing database layout.

Someone may have to raise a support ticket mentioning that the #bug is still there.

Reposted with #public visibility. Sorry for double message.
#Payara #Glassfish #EclipseLink #WilfFly #JPA) #JavaEE #bug #public bug eclipselink javaee jpa payara
Nothing new here so far. Only they asked me to write a test-case for them ... :-(

Glasfish / Payara sometimes throw ClassCastException

I sometimes get this error message after I have redeployed (also with in-place deployment) a WAR project and have tried to use a JSF form:
Warnung: StandardWrapperValve[Faces Servlet]: Servlet.service() for servlet Faces Servlet threw exception
java.lang.ClassCastException: Object is not of remote type java.rmi.Remote
at com.sun.corba.ee.impl.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:254)
at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:150)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl$12.read(DynamicMethodMarshallerImpl.java:352)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl.readResult(DynamicMethodMarshallerImpl.java:482)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:201)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:150)
at com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:226)
at com.sun.ejb.codegen._GenericEJBHome_Generated_DynamicStub.create(com/sun/ejb/codegen/_GenericEJBHome_Generated_DynamicStub.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.sun.ejb.EJBUtils.lookupRemote30BusinessObject(EJBUtils.java:421)
at com.sun.ejb.containers.RemoteBusinessObjectFactory.getObjectInstance(RemoteBusinessObjectFactory.java:75)
at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:321)
at com.sun.enterprise.naming.impl.SerialContext.getObjectInstance(SerialContext.java:527)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:487)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:438)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at de.chotime.jreports.beans.contact.ReportsContactWebSessionBean.<init>(ReportsContactWebSessionBean.java:237)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.jboss.weld.injection.ConstructorInjectionPoint.newInstance(ConstructorInjectionPoint.java:119)
at org.jboss.weld.injection.ConstructorInjectionPoint.invokeAroundConstructCallbacks(ConstructorInjectionPoint.java:92)
at org.jboss.weld.injection.ConstructorInjectionPoint.newInstance(ConstructorInjectionPoint.java:78)
at org.jboss.weld.injection.producer.AbstractInstantiator.newInstance(AbstractInstantiator.java:28)
at org.jboss.weld.injection.producer.BasicInjectionTarget.produce(BasicInjectionTarget.java:116)
at org.jboss.weld.injection.producer.BeanInjectionTarget.produce(BeanInjectionTarget.java:180)
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:158)
at org.jboss.weld.util.bean.IsolatedForwardingBean.create(IsolatedForwardingBean.java:45)
at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96)
at org.jboss.weld.context.PassivatingContextWrapper$AbstractPassivatingContextWrapper.get(PassivatingContextWrapper.java:76)
at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101)
at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.get(ContextualInstanceStrategy.java:178)
at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:67)
at org.jboss.weld.event.ObserverMethodImpl.getReceiver(ObserverMethodImpl.java:339)
at org.jboss.weld.event.ObserverMethodImpl.getReceiverIfExists(ObserverMethodImpl.java:326)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:284)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:265)
at org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:271)
at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:260)
at org.jboss.weld.event.EventImpl.fire(EventImpl.java:89)
at de.chotime.jreports.beans.login.ReportsUserLoginWebSessionBean.doUserLogin(ReportsUserLoginWebSessionBean.java:170)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at javax.el.ELUtil.invokeMethod(ELUtil.java:332)
at javax.el.BeanELResolver.invoke(BeanELResolver.java:537)
at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:256)
at com.sun.el.parser.AstValue.invoke(AstValue.java:283)
at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304)
at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40)
at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50)
at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105)
at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:87)
at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102)
at javax.faces.component.UICommand.broadcast(UICommand.java:315)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:790)
at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1282)
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:658)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:344)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.apache.logging.log4j.web.Log4jServletFilter.doFilter(Log4jServletFilter.java:71)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:316)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:416)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:283)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:206)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:526)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:591)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
at java.lang.Thread.run(Thread.java:745)


My previous #JavaEE trainer said it is a bug in #Glassfish / #Payara but it starts to become more anoying. Does someone know something to prevent this from happening?

Yes, filling out a bug report may help. :-) But maybe there is a trick or so?

The most "outter" exception says:
javax.servlet.ServletException: javax.faces.view.facelets.FaceletException: javax.naming.NamingException: Lookup failed for 'java:global/jreports-ejb/contact!org.mxchange.jcontacts.contact.ContactSessionBeanRemote' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming} [Root exception is javax.naming.NamingException: ejb ref resolution error for remote business interfaceorg.mxchange.jcontacts.contact.ContactSessionBeanRemote [Root exception is java.lang.ClassCastException]]


The interface in question (see the JNDI string end) "ContactSessionBeanRemote" is annotated with @Remote (javax.ejb.Remote) and not java.rmi.Remote as the exception says.

It is declared as following:
public interface ContactSessionBeanRemote extends Serializable {
...
}
#JavaEE #Glassfish #Payara bug glassfish javaee payara
Later posts Earlier posts