Re: multithreaded repository issues
Thats nice :-) Yepp, I know, however I've been testing different scope on em's. Having @requestscoped em, each managed thread will use its own em proxy ref every cycle Having dependent, each managed thread will get a new em proxy ref. I have not yet been able to get the same on using DS repositories, so I'm very happy for any feedback, whatever they may be :-) br hw -- View this message in context: http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/multithreaded-repository-issues-tp4660132p4660166.html Sent from the Apache DeltaSpike Incubator Discussions mailing list archive at Nabble.com.
Re: multithreaded repository issues
Thanks! Hope I'll get some time soon to have a detailed look. RE concurrency: My initial impression is that calling Runnables out of a @Singleton with a @RequestScoped EM might lead to interesting results ;-) Probably we have to sort this out first. On Mon, Mar 16, 2015 at 12:57 PM, hwaastad wrote: > Hi guys, > > made a simple project: > > https://github.com/hwaastad/DeltaDataPerformance.git > > two IT's > one using em only and the other ds repository. > > Tune number of generated records in abstractContainerTest. > > Please mind that I've not made any timer interceptors for providing time, > but then again both tests use the same strategy. > It's just made for proving difference. > > Some details: > TomEE 1.7.1 as container > eclipselink 2.5.2 > hsql embedded in tomee as db > > You may choose to use another db by changing datasource in > container.properties. > > br, > hw > > > > -- > View this message in context: > http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/multithreaded-repository-issues-tp4660132p4660152.html > Sent from the Apache DeltaSpike Incubator Discussions mailing list archive > at Nabble.com. >
Re: multithreaded repository issues
Hi guys, made a simple project: https://github.com/hwaastad/DeltaDataPerformance.git two IT's one using em only and the other ds repository. Tune number of generated records in abstractContainerTest. Please mind that I've not made any timer interceptors for providing time, but then again both tests use the same strategy. It's just made for proving difference. Some details: TomEE 1.7.1 as container eclipselink 2.5.2 hsql embedded in tomee as db You may choose to use another db by changing datasource in container.properties. br, hw -- View this message in context: http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/multithreaded-repository-issues-tp4660132p4660152.html Sent from the Apache DeltaSpike Incubator Discussions mailing list archive at Nabble.com.
Re: multithreaded repository issues
Static information and validation is indeed computed after bean discovery, but there are various injections happening during each call. Might also be interesting to see how different scopes can impact performance (e.g. AppScoped repositories vs. dependent). On Sun, Mar 15, 2015 at 10:42 PM, Karl Kildén wrote: > Hello, > > I have not really noticed any perf issues with deltaspike data but then > again I did not measure it either. We use it a lot. Would be great to learn > more about it for sure. > > I always assumed the method name query syntax and the other static stuff > would be cached etc so I don't really get why it would be any major penalty > all though I understand each abstraction will have some kind of impact... > > > > > On 15 March 2015 at 21:40, hwaastad wrote: > > > Hi guys, > > and thanks for answering. > > > > I'll try to get something out on github tomorrow. > > > > Br hw > > > > > > > > -- > > View this message in context: > > > http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/multithreaded-repository-issues-tp4660132p4660145.html > > Sent from the Apache DeltaSpike Incubator Discussions mailing list > archive > > at Nabble.com. > > >
Re: multithreaded repository issues
Hello, I have not really noticed any perf issues with deltaspike data but then again I did not measure it either. We use it a lot. Would be great to learn more about it for sure. I always assumed the method name query syntax and the other static stuff would be cached etc so I don't really get why it would be any major penalty all though I understand each abstraction will have some kind of impact... On 15 March 2015 at 21:40, hwaastad wrote: > Hi guys, > and thanks for answering. > > I'll try to get something out on github tomorrow. > > Br hw > > > > -- > View this message in context: > http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/multithreaded-repository-issues-tp4660132p4660145.html > Sent from the Apache DeltaSpike Incubator Discussions mailing list archive > at Nabble.com. >
Re: multithreaded repository issues
Hi guys, and thanks for answering. I'll try to get something out on github tomorrow. Br hw -- View this message in context: http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/multithreaded-repository-issues-tp4660132p4660145.html Sent from the Apache DeltaSpike Incubator Discussions mailing list archive at Nabble.com.
Re: multithreaded repository issues
> The overhead is definitely expected. But I agree it would be interesting to > get the split between CDI, PartialBean and Data. > Yep, i'm interested, too! We already use it widely in our apps and i never checked the performance of the data module. PartialBean overhead should be minimal since 1.3.0.
Re: multithreaded repository issues
Hi The Data module works mainly with dependent scope and a ThreadLocal. Anything ApplicationScoped around which could pull in the dependent beans? Example projects we like always best when it comes to defect reports :-) The overhead is definitely expected. But I agree it would be interesting to get the split between CDI, PartialBean and Data. Cheers, Thomas On Sat, Mar 14, 2015 at 8:36 PM, hwaastad wrote: > Hi, > I'm playing around with repositories and testing out multithreaded jpa > transactions. > I know discussions around em thread safety etc :-) > > Anyways, > My current setup Im using managedexecutorservice and running 4 parallell > jobs each store or merge an Set of entities. > No duplicates. > Runnable is using UserTransaction. > DS 1.3.0 > JTA and JTA em. > > If I'm only injecting em I never have issues. > Using deltaspike, I get (and not always, but usually at merge): > > java.util.concurrent.ExecutionException: > org.apache.deltaspike.data.api.QueryInvocationException: Failed calling > Repository: > > [Repository=org.waastad.productcatalog.repository.FlatProductRepository,entity=org.waastad.entity.FlatProduct,method=findBy,exception=class > org.apache.deltaspike.data.api.QueryInvocationException,message=Failed > calling Repository: > > [Repository=org.waastad.productcatalog.repository.FlatProductRepository,entity=org.waastad.entity.FlatProduct,method=findBy,exception=class > java.lang.NullPointerException,message=null > . > . > . > . > java.lang.NullPointerException,message=null > at > > org.apache.deltaspike.data.impl.builder.DelegateQueryBuilder.execute(DelegateQueryBuilder.java:66) > at > > org.apache.deltaspike.data.impl.builder.QueryBuilder.executeQuery(QueryBuilder.java:57) > at > > org.apache.deltaspike.data.impl.tx.TransactionalQueryRunner.executeNonTransactional(TransactionalQueryRunner.java:66) > at > > org.apache.deltaspike.data.impl.tx.TransactionalQueryRunner.executeQuery(TransactionalQueryRunner.java:61) > at > > org.apache.deltaspike.data.impl.handler.QueryHandler.invoke(QueryHandler.java:79) > > I can make you an example project if you're interested. > > I'm probably pushing jpa since im importing ~1.5 mill in batch jobs, but as > I was sayingI'am testing :-) > > BTW, > penalty using repositories are quite high compared to only using em (~50% > )...which probably is as expected, not? > > > br hw > > > > -- > View this message in context: > http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/multithreaded-repository-issues-tp4660132.html > Sent from the Apache DeltaSpike Incubator Discussions mailing list archive > at Nabble.com. >
multithreaded repository issues
Hi, I'm playing around with repositories and testing out multithreaded jpa transactions. I know discussions around em thread safety etc :-) Anyways, My current setup Im using managedexecutorservice and running 4 parallell jobs each store or merge an Set of entities. No duplicates. Runnable is using UserTransaction. DS 1.3.0 JTA and JTA em. If I'm only injecting em I never have issues. Using deltaspike, I get (and not always, but usually at merge): java.util.concurrent.ExecutionException: org.apache.deltaspike.data.api.QueryInvocationException: Failed calling Repository: [Repository=org.waastad.productcatalog.repository.FlatProductRepository,entity=org.waastad.entity.FlatProduct,method=findBy,exception=class org.apache.deltaspike.data.api.QueryInvocationException,message=Failed calling Repository: [Repository=org.waastad.productcatalog.repository.FlatProductRepository,entity=org.waastad.entity.FlatProduct,method=findBy,exception=class java.lang.NullPointerException,message=null . . . . java.lang.NullPointerException,message=null at org.apache.deltaspike.data.impl.builder.DelegateQueryBuilder.execute(DelegateQueryBuilder.java:66) at org.apache.deltaspike.data.impl.builder.QueryBuilder.executeQuery(QueryBuilder.java:57) at org.apache.deltaspike.data.impl.tx.TransactionalQueryRunner.executeNonTransactional(TransactionalQueryRunner.java:66) at org.apache.deltaspike.data.impl.tx.TransactionalQueryRunner.executeQuery(TransactionalQueryRunner.java:61) at org.apache.deltaspike.data.impl.handler.QueryHandler.invoke(QueryHandler.java:79) I can make you an example project if you're interested. I'm probably pushing jpa since im importing ~1.5 mill in batch jobs, but as I was sayingI'am testing :-) BTW, penalty using repositories are quite high compared to only using em (~50% )...which probably is as expected, not? br hw -- View this message in context: http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/multithreaded-repository-issues-tp4660132.html Sent from the Apache DeltaSpike Incubator Discussions mailing list archive at Nabble.com.
