Spring, Interceptors, some ExtJs and a HibernateException on console vs IntelliJ
Weired world... let me try:
I have the follwing mavenized setup:
- Springboot (1.5.5.RELEASE)
- Hibernate (5.0.9.Final; I do know there is newer variants but I stick with what I have right now)
- ExtJs (6.0.0)
- IntelliJ (2017.3)
I do partly get running into an Hibernate Exception:
2018-11-20_15:04:58.007 [http-nio-8081-exec-7] [ERROR] o.a.c.c.C.[.[.[/].[dispatcherServlet]:181 - Servlet.service() for servlet [dispatcherServlet] in context with path threw exception [Request processing failed; nested exception is org.hibernate.HibernateException:
Could not obtain transaction-synchronized Session for current thread] with root cause
org.hibernate.HibernateException: Could not obtain transaction-synchronized Session for current thread
at org.springframework.orm.hibernate5.SpringSessionContext.currentSession(SpringSessionContext.java:133)
at org.hibernate.internal.SessionFactoryImpl.getCurrentSession(SessionFactoryImpl.java:697)
...
This does not happen on all threads! Partly the requests from ExtJs go through, Partly they don't. But would they not open a transaction on the webserver side?
I do have an Interceptor; well a web Interceptor implementing org.springframework.web.servlet.HandlerInterceptor
Within the interceptor's preHandle
method I do call a Service in order to check if a user is logged in and do some rights management handling.
The called @Autowired
service fails. I thought the fact of accessing an @Autowired
service method takes care of session/transaction handling.
Well, this was the scenario having my project manually created and run with a java-8 (java 8 sdk; not 9, not 10, not 11) command like from the console:
mvn clean package -DskipTests && java -jar target/MyBuild.jar application-local.properties
I just observed that the login consists of three request from browser to the backend. These three are all handled in separate threads by the backend.
When running the project within IntelliJ it all works fine. Ok, IntelliJ most likely does not jar the application and builds its own startup command.
But exactly that brings me out of rhythm due to the fact that we do process the code through a deployment / CI pipeline where we manually build the project.
And that is where it fails :-(
Amendment:
I changed everything to run with JPA instead of Hibernate (well it is still hibernate in the background). Just as 'M. Deinum' suggested.
Now, the problem still exists.
Two things I somewhat extracted.
In my Interceptor I do have some logging calls which ask the EntityManager for a hibernate-session (entityManager.unwrap( Session.class )
).
This is the point where now.
So it seems that on the preHandle(...)
of my interceptor there is sometimes no current session active. I am stating 'sometimes' since there are calls to the Interceptor when it works.
The exception comes as following now:
java.lang.IllegalStateException: No transactional EntityManager available
at org.springframework.orm.jpa.SharedEntityManagerCreator$SharedEntityManagerInvocationHandler.invoke(SharedEntityManagerCreator.java:272)
at com.sun.proxy.$Proxy117.unwrap(Unknown Source)
at com.mypackage.dataaccess.DataAccessImpl.getCurrentSession(DataAccessImpl.java:89)
at com.mypackage.dataaccess.DataAccessImpl.queryByHQL(DataAccessImpl.java:382)
java database spring hibernate interceptor
add a comment |
Weired world... let me try:
I have the follwing mavenized setup:
- Springboot (1.5.5.RELEASE)
- Hibernate (5.0.9.Final; I do know there is newer variants but I stick with what I have right now)
- ExtJs (6.0.0)
- IntelliJ (2017.3)
I do partly get running into an Hibernate Exception:
2018-11-20_15:04:58.007 [http-nio-8081-exec-7] [ERROR] o.a.c.c.C.[.[.[/].[dispatcherServlet]:181 - Servlet.service() for servlet [dispatcherServlet] in context with path threw exception [Request processing failed; nested exception is org.hibernate.HibernateException:
Could not obtain transaction-synchronized Session for current thread] with root cause
org.hibernate.HibernateException: Could not obtain transaction-synchronized Session for current thread
at org.springframework.orm.hibernate5.SpringSessionContext.currentSession(SpringSessionContext.java:133)
at org.hibernate.internal.SessionFactoryImpl.getCurrentSession(SessionFactoryImpl.java:697)
...
This does not happen on all threads! Partly the requests from ExtJs go through, Partly they don't. But would they not open a transaction on the webserver side?
I do have an Interceptor; well a web Interceptor implementing org.springframework.web.servlet.HandlerInterceptor
Within the interceptor's preHandle
method I do call a Service in order to check if a user is logged in and do some rights management handling.
The called @Autowired
service fails. I thought the fact of accessing an @Autowired
service method takes care of session/transaction handling.
Well, this was the scenario having my project manually created and run with a java-8 (java 8 sdk; not 9, not 10, not 11) command like from the console:
mvn clean package -DskipTests && java -jar target/MyBuild.jar application-local.properties
I just observed that the login consists of three request from browser to the backend. These three are all handled in separate threads by the backend.
When running the project within IntelliJ it all works fine. Ok, IntelliJ most likely does not jar the application and builds its own startup command.
But exactly that brings me out of rhythm due to the fact that we do process the code through a deployment / CI pipeline where we manually build the project.
And that is where it fails :-(
Amendment:
I changed everything to run with JPA instead of Hibernate (well it is still hibernate in the background). Just as 'M. Deinum' suggested.
Now, the problem still exists.
Two things I somewhat extracted.
In my Interceptor I do have some logging calls which ask the EntityManager for a hibernate-session (entityManager.unwrap( Session.class )
).
This is the point where now.
So it seems that on the preHandle(...)
of my interceptor there is sometimes no current session active. I am stating 'sometimes' since there are calls to the Interceptor when it works.
The exception comes as following now:
java.lang.IllegalStateException: No transactional EntityManager available
at org.springframework.orm.jpa.SharedEntityManagerCreator$SharedEntityManagerInvocationHandler.invoke(SharedEntityManagerCreator.java:272)
at com.sun.proxy.$Proxy117.unwrap(Unknown Source)
at com.mypackage.dataaccess.DataAccessImpl.getCurrentSession(DataAccessImpl.java:89)
at com.mypackage.dataaccess.DataAccessImpl.queryByHQL(DataAccessImpl.java:382)
java database spring hibernate interceptor
Why are you using plain Hibernate instead of JPA? auto wiring and starting transactions have nothing to do with each other.
– M. Deinum
Nov 21 '18 at 9:35
1st: Using Hibernate instead of JPA is reasoned so far on old code setup. I agree not doing so. But I did not want to keep this refactoring as small as possible. I do agree. But would that help me right now? I already tried to use up2date hibernate libs + entitymanager instead if SessionFactory but did not succeed. - 2nd: I somewhat agree and disagree on the connection with @Autowire and @Transactional. Using an autowired service method which is annotated with @Transactional does the session handling. The dependency injection and injected references do handle the tx management. Don't they?
– Dirk Schumacher
Nov 21 '18 at 10:08
The@Transactional
is what manages the transactionality. Not the fact that you autowire something.
– M. Deinum
Nov 21 '18 at 11:01
add a comment |
Weired world... let me try:
I have the follwing mavenized setup:
- Springboot (1.5.5.RELEASE)
- Hibernate (5.0.9.Final; I do know there is newer variants but I stick with what I have right now)
- ExtJs (6.0.0)
- IntelliJ (2017.3)
I do partly get running into an Hibernate Exception:
2018-11-20_15:04:58.007 [http-nio-8081-exec-7] [ERROR] o.a.c.c.C.[.[.[/].[dispatcherServlet]:181 - Servlet.service() for servlet [dispatcherServlet] in context with path threw exception [Request processing failed; nested exception is org.hibernate.HibernateException:
Could not obtain transaction-synchronized Session for current thread] with root cause
org.hibernate.HibernateException: Could not obtain transaction-synchronized Session for current thread
at org.springframework.orm.hibernate5.SpringSessionContext.currentSession(SpringSessionContext.java:133)
at org.hibernate.internal.SessionFactoryImpl.getCurrentSession(SessionFactoryImpl.java:697)
...
This does not happen on all threads! Partly the requests from ExtJs go through, Partly they don't. But would they not open a transaction on the webserver side?
I do have an Interceptor; well a web Interceptor implementing org.springframework.web.servlet.HandlerInterceptor
Within the interceptor's preHandle
method I do call a Service in order to check if a user is logged in and do some rights management handling.
The called @Autowired
service fails. I thought the fact of accessing an @Autowired
service method takes care of session/transaction handling.
Well, this was the scenario having my project manually created and run with a java-8 (java 8 sdk; not 9, not 10, not 11) command like from the console:
mvn clean package -DskipTests && java -jar target/MyBuild.jar application-local.properties
I just observed that the login consists of three request from browser to the backend. These three are all handled in separate threads by the backend.
When running the project within IntelliJ it all works fine. Ok, IntelliJ most likely does not jar the application and builds its own startup command.
But exactly that brings me out of rhythm due to the fact that we do process the code through a deployment / CI pipeline where we manually build the project.
And that is where it fails :-(
Amendment:
I changed everything to run with JPA instead of Hibernate (well it is still hibernate in the background). Just as 'M. Deinum' suggested.
Now, the problem still exists.
Two things I somewhat extracted.
In my Interceptor I do have some logging calls which ask the EntityManager for a hibernate-session (entityManager.unwrap( Session.class )
).
This is the point where now.
So it seems that on the preHandle(...)
of my interceptor there is sometimes no current session active. I am stating 'sometimes' since there are calls to the Interceptor when it works.
The exception comes as following now:
java.lang.IllegalStateException: No transactional EntityManager available
at org.springframework.orm.jpa.SharedEntityManagerCreator$SharedEntityManagerInvocationHandler.invoke(SharedEntityManagerCreator.java:272)
at com.sun.proxy.$Proxy117.unwrap(Unknown Source)
at com.mypackage.dataaccess.DataAccessImpl.getCurrentSession(DataAccessImpl.java:89)
at com.mypackage.dataaccess.DataAccessImpl.queryByHQL(DataAccessImpl.java:382)
java database spring hibernate interceptor
Weired world... let me try:
I have the follwing mavenized setup:
- Springboot (1.5.5.RELEASE)
- Hibernate (5.0.9.Final; I do know there is newer variants but I stick with what I have right now)
- ExtJs (6.0.0)
- IntelliJ (2017.3)
I do partly get running into an Hibernate Exception:
2018-11-20_15:04:58.007 [http-nio-8081-exec-7] [ERROR] o.a.c.c.C.[.[.[/].[dispatcherServlet]:181 - Servlet.service() for servlet [dispatcherServlet] in context with path threw exception [Request processing failed; nested exception is org.hibernate.HibernateException:
Could not obtain transaction-synchronized Session for current thread] with root cause
org.hibernate.HibernateException: Could not obtain transaction-synchronized Session for current thread
at org.springframework.orm.hibernate5.SpringSessionContext.currentSession(SpringSessionContext.java:133)
at org.hibernate.internal.SessionFactoryImpl.getCurrentSession(SessionFactoryImpl.java:697)
...
This does not happen on all threads! Partly the requests from ExtJs go through, Partly they don't. But would they not open a transaction on the webserver side?
I do have an Interceptor; well a web Interceptor implementing org.springframework.web.servlet.HandlerInterceptor
Within the interceptor's preHandle
method I do call a Service in order to check if a user is logged in and do some rights management handling.
The called @Autowired
service fails. I thought the fact of accessing an @Autowired
service method takes care of session/transaction handling.
Well, this was the scenario having my project manually created and run with a java-8 (java 8 sdk; not 9, not 10, not 11) command like from the console:
mvn clean package -DskipTests && java -jar target/MyBuild.jar application-local.properties
I just observed that the login consists of three request from browser to the backend. These three are all handled in separate threads by the backend.
When running the project within IntelliJ it all works fine. Ok, IntelliJ most likely does not jar the application and builds its own startup command.
But exactly that brings me out of rhythm due to the fact that we do process the code through a deployment / CI pipeline where we manually build the project.
And that is where it fails :-(
Amendment:
I changed everything to run with JPA instead of Hibernate (well it is still hibernate in the background). Just as 'M. Deinum' suggested.
Now, the problem still exists.
Two things I somewhat extracted.
In my Interceptor I do have some logging calls which ask the EntityManager for a hibernate-session (entityManager.unwrap( Session.class )
).
This is the point where now.
So it seems that on the preHandle(...)
of my interceptor there is sometimes no current session active. I am stating 'sometimes' since there are calls to the Interceptor when it works.
The exception comes as following now:
java.lang.IllegalStateException: No transactional EntityManager available
at org.springframework.orm.jpa.SharedEntityManagerCreator$SharedEntityManagerInvocationHandler.invoke(SharedEntityManagerCreator.java:272)
at com.sun.proxy.$Proxy117.unwrap(Unknown Source)
at com.mypackage.dataaccess.DataAccessImpl.getCurrentSession(DataAccessImpl.java:89)
at com.mypackage.dataaccess.DataAccessImpl.queryByHQL(DataAccessImpl.java:382)
java database spring hibernate interceptor
java database spring hibernate interceptor
edited Nov 21 '18 at 14:01
Dirk Schumacher
asked Nov 21 '18 at 8:35
Dirk SchumacherDirk Schumacher
738822
738822
Why are you using plain Hibernate instead of JPA? auto wiring and starting transactions have nothing to do with each other.
– M. Deinum
Nov 21 '18 at 9:35
1st: Using Hibernate instead of JPA is reasoned so far on old code setup. I agree not doing so. But I did not want to keep this refactoring as small as possible. I do agree. But would that help me right now? I already tried to use up2date hibernate libs + entitymanager instead if SessionFactory but did not succeed. - 2nd: I somewhat agree and disagree on the connection with @Autowire and @Transactional. Using an autowired service method which is annotated with @Transactional does the session handling. The dependency injection and injected references do handle the tx management. Don't they?
– Dirk Schumacher
Nov 21 '18 at 10:08
The@Transactional
is what manages the transactionality. Not the fact that you autowire something.
– M. Deinum
Nov 21 '18 at 11:01
add a comment |
Why are you using plain Hibernate instead of JPA? auto wiring and starting transactions have nothing to do with each other.
– M. Deinum
Nov 21 '18 at 9:35
1st: Using Hibernate instead of JPA is reasoned so far on old code setup. I agree not doing so. But I did not want to keep this refactoring as small as possible. I do agree. But would that help me right now? I already tried to use up2date hibernate libs + entitymanager instead if SessionFactory but did not succeed. - 2nd: I somewhat agree and disagree on the connection with @Autowire and @Transactional. Using an autowired service method which is annotated with @Transactional does the session handling. The dependency injection and injected references do handle the tx management. Don't they?
– Dirk Schumacher
Nov 21 '18 at 10:08
The@Transactional
is what manages the transactionality. Not the fact that you autowire something.
– M. Deinum
Nov 21 '18 at 11:01
Why are you using plain Hibernate instead of JPA? auto wiring and starting transactions have nothing to do with each other.
– M. Deinum
Nov 21 '18 at 9:35
Why are you using plain Hibernate instead of JPA? auto wiring and starting transactions have nothing to do with each other.
– M. Deinum
Nov 21 '18 at 9:35
1st: Using Hibernate instead of JPA is reasoned so far on old code setup. I agree not doing so. But I did not want to keep this refactoring as small as possible. I do agree. But would that help me right now? I already tried to use up2date hibernate libs + entitymanager instead if SessionFactory but did not succeed. - 2nd: I somewhat agree and disagree on the connection with @Autowire and @Transactional. Using an autowired service method which is annotated with @Transactional does the session handling. The dependency injection and injected references do handle the tx management. Don't they?
– Dirk Schumacher
Nov 21 '18 at 10:08
1st: Using Hibernate instead of JPA is reasoned so far on old code setup. I agree not doing so. But I did not want to keep this refactoring as small as possible. I do agree. But would that help me right now? I already tried to use up2date hibernate libs + entitymanager instead if SessionFactory but did not succeed. - 2nd: I somewhat agree and disagree on the connection with @Autowire and @Transactional. Using an autowired service method which is annotated with @Transactional does the session handling. The dependency injection and injected references do handle the tx management. Don't they?
– Dirk Schumacher
Nov 21 '18 at 10:08
The
@Transactional
is what manages the transactionality. Not the fact that you autowire something.– M. Deinum
Nov 21 '18 at 11:01
The
@Transactional
is what manages the transactionality. Not the fact that you autowire something.– M. Deinum
Nov 21 '18 at 11:01
add a comment |
1 Answer
1
active
oldest
votes
Ok. I ended up noting all Spring web controllers to have an @Transactional (where DB usage is given.)
That works.
From my understanding it does not matter where to put the @Transactional annotation as long as the method/owning Object is invoked through spring's @Autowire mechanism.
If I want something to run under the transactional behaviour I would annotated with it on the closest scope possible.
That's how I would decide where to put the @Transactional
At the end it does work but I am not satisfied with the solution.
If anyone could clarify the behaviour and/or my understanding let me welcomely know :-)
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53408036%2fspring-interceptors-some-extjs-and-a-hibernateexception-on-console-vs-intellij%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Ok. I ended up noting all Spring web controllers to have an @Transactional (where DB usage is given.)
That works.
From my understanding it does not matter where to put the @Transactional annotation as long as the method/owning Object is invoked through spring's @Autowire mechanism.
If I want something to run under the transactional behaviour I would annotated with it on the closest scope possible.
That's how I would decide where to put the @Transactional
At the end it does work but I am not satisfied with the solution.
If anyone could clarify the behaviour and/or my understanding let me welcomely know :-)
add a comment |
Ok. I ended up noting all Spring web controllers to have an @Transactional (where DB usage is given.)
That works.
From my understanding it does not matter where to put the @Transactional annotation as long as the method/owning Object is invoked through spring's @Autowire mechanism.
If I want something to run under the transactional behaviour I would annotated with it on the closest scope possible.
That's how I would decide where to put the @Transactional
At the end it does work but I am not satisfied with the solution.
If anyone could clarify the behaviour and/or my understanding let me welcomely know :-)
add a comment |
Ok. I ended up noting all Spring web controllers to have an @Transactional (where DB usage is given.)
That works.
From my understanding it does not matter where to put the @Transactional annotation as long as the method/owning Object is invoked through spring's @Autowire mechanism.
If I want something to run under the transactional behaviour I would annotated with it on the closest scope possible.
That's how I would decide where to put the @Transactional
At the end it does work but I am not satisfied with the solution.
If anyone could clarify the behaviour and/or my understanding let me welcomely know :-)
Ok. I ended up noting all Spring web controllers to have an @Transactional (where DB usage is given.)
That works.
From my understanding it does not matter where to put the @Transactional annotation as long as the method/owning Object is invoked through spring's @Autowire mechanism.
If I want something to run under the transactional behaviour I would annotated with it on the closest scope possible.
That's how I would decide where to put the @Transactional
At the end it does work but I am not satisfied with the solution.
If anyone could clarify the behaviour and/or my understanding let me welcomely know :-)
answered Jan 14 at 11:14
Dirk SchumacherDirk Schumacher
738822
738822
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53408036%2fspring-interceptors-some-extjs-and-a-hibernateexception-on-console-vs-intellij%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Why are you using plain Hibernate instead of JPA? auto wiring and starting transactions have nothing to do with each other.
– M. Deinum
Nov 21 '18 at 9:35
1st: Using Hibernate instead of JPA is reasoned so far on old code setup. I agree not doing so. But I did not want to keep this refactoring as small as possible. I do agree. But would that help me right now? I already tried to use up2date hibernate libs + entitymanager instead if SessionFactory but did not succeed. - 2nd: I somewhat agree and disagree on the connection with @Autowire and @Transactional. Using an autowired service method which is annotated with @Transactional does the session handling. The dependency injection and injected references do handle the tx management. Don't they?
– Dirk Schumacher
Nov 21 '18 at 10:08
The
@Transactional
is what manages the transactionality. Not the fact that you autowire something.– M. Deinum
Nov 21 '18 at 11:01