I’m using jboss and cmt and have seen strange behaviour when using requires_new on an ejb method that I loop over from another bean to insert some records.
I see that intermittently after restarting the jboss the operations in the method aren’t committed to db after the method is finished.So, I have tried to use TransactionSynchronizationRegistry and found that when the data isn’t committed I actually don’t get a new transaction each time the method is entered. Anyone who has heard of jboss acting this way? I'm using ejb, jboss, jpa, Hibernate, cmt.
So, I've finally solved this problem. I used this great blog post
http://piotrnowicki.com/2011/11/am-i-in-the-same-transaction-am-i-using-the-same-persistencecontext/
to make sure that I actually was in the same transaction after entering the method annotated REQUIRES_NEW. So then I understood that JBoss intermittently ignored the annotation and defaulted to REQUIRED instead. This was because multiple classes implemented the same interface. So I simplified it so that I now have one interface, annotated #Local, and one implementing class where the REQUIRES_NEW annotated method is.
I understand that in this case it was our code that was wrong so it's not really a bug in Jboss way of handling transactions. But it's really strange that there isn't as much as a warning in the logs that there is a race condition. I could restart the Jboss and get a different behavior than before the restart. I think that's strange. I haven't found much about that this could be a problem after googling so I hope that this answer can save some time for someone else.
Edit:
It's not about multiple implementing classes, just about declaring all the methods in the interface annotated #Local, otherwise JBoss might ignore the attributes
Related
Is it possible to use EclipseLink with QUarkus? Or is Quarkus too hardly coupled with Hibernate?
We are in the process of choosing our MP implementation and we want to stick as close to the reference impls as possible
I am not seeing much information on https://quarkus.io/guides/ or even this very forum to indicate that eclipselink too can be used with Quarkus.
Any pointers on why Quarkus is tied so tightly to a specific impl (if it is) of JPA would also be welcome
TIA
Rahul
You can use EclipseLink by adding it in your classpath as fxrobin mentioned. But it won't work for native image generation, nor will be integrated with the database connection pool, the transaction enlistment etc. Finally the startup time will be much longer.
The reason Quarkus focuses on Hibernate ORM is exactly for these reasons. Making Hibernate ORM work on native, making it do work at build time to speed startup time, smoothly integrating it with other areas takes a lot of time. Someone could make the same for EclipseLink with a few months of work ahead of them.
You can add EclipseLink in a class way as if you were in Java SE. But then you have to manage the transactional behaviour by code but not with annotations.
After updating to .net core 2.2 we have the following issue:
Autofac.Core.Registration.ComponentNotRegisteredException: 'The
requested service 'Microsoft.AspNetCore.Hosting.Server.IServer' has
not been registered. To avoid this exception, either register a
component to provide the service, check for service registration using
IsRegistered(), or use the ResolveOptional() method to resolve an
optional dependency.'
We are using preBuilder.Populate(services);.
Any ideas?
Thanks for your help
I had the same problem when following Microsoft migration guide for migrating from Core 2.1 to 2.2.
The problem might occur if you are not using WebHost.CreateDefaultBuilder to create the default web host builder, and you change in the CreateWebHostBuilder method of the Program class to call ConfigureKestrel instead of UseKestrel, as suggested in the migration guide.
As far as I understand if you use WebHost.CreateDefaultBuilder to create the default web host builder, it already calls UseKestrel which registers the IServer service. But you might get into some conflicts if also using UseIIS, so to avoid this problems there is a new ConfigureKestrel call that does not register the IServer. So I think that if you are not using WebHost.CreateDefaultBuilder then you still need to call UseKestrel or UseIIS explicitly.
Of course it might be something else that is causing the problems in your case, but I suspect that following the migration guide blindly (as I did) could cause problems for many developers out there.
GWT's servlet implementation has onBefore/onAfterDeserialization which would give me a hook with which to start and stop transactions without doing anything fancy, however those methods don't allow me to properly check for error conditions after the service method got invoked, I just have access to the serialized return value, not directly to any exception that might have been thrown, so deciding whether to roll back or not is not possible that way without rewriting parts the GWT servlet.
I was thinking about using aspectj's compile-time weaving. However, this does not work with Netbeans' compile-on-save feature because the module needs to be recompiled using the aspectj compiler.
How about LTW (load-time-weaving)? Is there any way (or example) to add LTW to the webapp container without using the Spring framework?
I was also thinking about using AOP based on Java dynamic proxies, ie. to put a proxy in front of the servlet. Again, the question arises how to tell the Jetty WebApp container to load the proxy instead of the original servlet.
Or is there any ready-to-use solution out there already?
I think you could overwrite a combination of
public String processCall(RPCRequest rpcRequest) from RemoteServiceServlet and RPC.invokeAndEncodeResponse to do what you want.
Not ideal, as you need to copy/paste a few lines of code, but they really are only a few.
I myself hit the same problems as I needed some customizations, and relevant methods didn't had the access modifier that I needed, so I ended up copy/pasting some portions.
I can't comment on the rest of your question, but I don't expect to find any ready-to-use solutions, as GWT-RPC doesn't seem to have any new fans out there; just people maintaining legacy systems. Therefore, I expect that you either don't find anything or find solutions that are no longer maintained.
this is a very basic question, and I'm kind of sorry, but I don't seem to be able to get a simple Tapestry-IOC based application to work with the built-in Tapestry JPA module.
The application is not necessarily meant as a web project so the dependencies are just tapestry-ioc and tapestry-jpa for the JPA integration. I used the hibernate-entitymanager before and everything worked fine. But I thought I might rather use the official JPA support of Tapestry.
So what I did was to get the above mentioned dependencies (in Tapestry version 5.3.7) and to write the beginning of a test.
This beginning looks like this
Registry registry = RegistryBuilder.buildAndStartupRegistry(MyModule.class);
EntityManager em = registry.getService(EntityManager.class);
That's all. Because as soon as I try this I get the error that no service would implement the EntityManager interface.
So I added the Tapestry JPA module:
Registry registry = RegistryBuilder.buildAndStartupRegistry(MyModule.class, JpaModule.class);
But then again I get an error that the JpaModule wants to contribute to the ApplicationStatePersistenceStrategySource service which is not present. This service seems to be defined in the TapestryModule so I did
Registry registry = RegistryBuilder.buildAndStartupRegistry(MyModule.class, JpaModule.class, TapestryModule.class);
But this causes an error due to the missing servlet API. So now I get to the point where I would have to define the web environment for Tapestry. But I don't want this, I just wanted to use the JPA integration.
Is this even possible? And if so, how do I do it? Following the documentation at http://tapestry.apache.org/integrating-with-jpa.html does not help in this regard.
Thank you very much for reading, any hint appreciated!
Quick answer -- I could be wrong -- but I thought Tapestry-jpa was intended for using JPA with Tapestry-core (the web framework). I don't think there would be any benefit over plain JPA in your case.
I have problem in creating a generic RequestContext that has common methods such as persist, update, remove and other Request classes extend this class. I got following exception :
com.google.web.bindery.requestfactory.server.ReportableException: Could not locate RequestContext operation
after some googling found this issue
and also this post.
and I think it's not resolved yet.
is there anyway to do this that I need not to repeat every method in all Request classes ?
Well, when a bug has been reported and is still open, then yes it's still not resolved, and as such, the workaround still applies. So no, there's no other way currently than re-declaring the methods in the subinterfaces.