JPA changes on DB not written before method finished Unicorn Meta Zoo #1: Why another podcast? Announcing the arrival of Valued Associate #679: Cesar Manara Data science time! April 2019 and salary with experience The Ask Question Wizard is Live!JPA EntityManager: Why use persist() over merge()?Is null check needed before calling instanceof?JPA transaction rollback retry and recovery: merging entity with auto-incremented @VersionWhat's the difference between JPA and Hibernate?How do I update an entity using spring-data-jpa?Gateway Pattern using Java EEWill JPA EntityManager's merge method lead to OptimisticLockException?JPA flush() in concurency OptimisticLockHow far does the scope of an entityManager reach?jpa flush or find before persist
What helicopter has the most rotor blades?
Can gravitational waves pass through a black hole?
Why do people think Winterfell crypts is the safest place for women, children & old people?
What is /etc/mtab in Linux?
Why aren't road bicycle wheels tiny?
What do you call an IPA symbol that lacks a name (e.g. ɲ)?
How was Lagrange appointed professor of mathematics so early?
What is the numbering system used for the DSN dishes?
Where can I find how to tex symbols for different fonts?
Processing ADC conversion result: DMA vs Processor Registers
How did Elite on the NES work?
RIP Packet Format
Why isn't everyone flabbergasted about Bran's "gift"?
TV series episode where humans nuke aliens before decrypting their message that states they come in peace
Will I be more secure with my own router behind my ISP's router?
Why does the Cisco show run command not show the full version, while the show version command does?
How can I wire a 9-position switch so that each position turns on one more LED than the one before?
Is it appropriate to mention a relatable company blog post when you're asked about the company?
Are there existing rules/lore for MTG planeswalkers?
Getting AggregateResult variables from Execute Anonymous Window
What is the evidence that custom checks in Northern Ireland are going to result in violence?
Mechanism of the formation of peracetic acid
Stretch a Tikz tree
What is a good proxy for government quality?
JPA changes on DB not written before method finished
Unicorn Meta Zoo #1: Why another podcast?
Announcing the arrival of Valued Associate #679: Cesar Manara
Data science time! April 2019 and salary with experience
The Ask Question Wizard is Live!JPA EntityManager: Why use persist() over merge()?Is null check needed before calling instanceof?JPA transaction rollback retry and recovery: merging entity with auto-incremented @VersionWhat's the difference between JPA and Hibernate?How do I update an entity using spring-data-jpa?Gateway Pattern using Java EEWill JPA EntityManager's merge method lead to OptimisticLockException?JPA flush() in concurency OptimisticLockHow far does the scope of an entityManager reach?jpa flush or find before persist
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;
I have a @Stateless-Bean which performs some Database operations in a single method
public void doOperation()
User u1 = createNewUser()
User u2 = createNewUser()
User updated = mergeUser(u1,u2) // just as an example
// should write to database now!
otherBlockingOperation()
However the changes are not visible in the database until the blocking operation finished and therefore not visible in the frontend.
I thought this is because the transaction is not committed until otherBlockingOperation() is finished. I then wrapped otherBlockingOperation() in a Thread, which did not work again.
However I think the real problem is merge which will only update the entity after the method is done. How can I change the values of Object instantly?
Edit:
@PersistanceContext
private EntityManager em;
mergeUser(T entity)
em.merge(entity);
em.flush();
java jpa java-ee java-ee-7
asked Mar 22 at 14:42
greedsingreedsin
386821
add a comment |
I have a @Stateless-Bean which performs some Database operations in a single method
public void doOperation()
User u1 = createNewUser()
User u2 = createNewUser()
User updated = mergeUser(u1,u2) // just as an example
// should write to database now!
otherBlockingOperation()
However the changes are not visible in the database until the blocking operation finished and therefore not visible in the frontend.
I thought this is because the transaction is not committed until otherBlockingOperation() is finished. I then wrapped otherBlockingOperation() in a Thread, which did not work again.
However I think the real problem is merge which will only update the entity after the method is done. How can I change the values of Object instantly?
Edit:
@PersistanceContext
private EntityManager em;
mergeUser(T entity)
em.merge(entity);
em.flush();
java jpa java-ee java-ee-7
asked Mar 22 at 14:42
greedsingreedsin
386821
Please provide the code ofmergeUser, this could be relevant. You are correct on your observation about transactions: In a@Statelessbean, a transaction is started (by default) and DB is updated only after transaction is committed. Even if youentityManager.flush()during the transaction, DB will be updated but still changes will be visible in your transaction only (unless some non-standard isolation level is used)
– Cascader
Mar 22 at 14:47
Also, managing your own threads in a JavaEE app is major no-no. The application server should be the only responsible for thread handling, using JavaEE methodology (i.e.@Asynchronousbusiness methods etc)
– Cascader
Mar 22 at 14:55
add a comment |
I have a @Stateless-Bean which performs some Database operations in a single method
public void doOperation()
User u1 = createNewUser()
User u2 = createNewUser()
User updated = mergeUser(u1,u2) // just as an example
// should write to database now!
otherBlockingOperation()
However the changes are not visible in the database until the blocking operation finished and therefore not visible in the frontend.
I thought this is because the transaction is not committed until otherBlockingOperation() is finished. I then wrapped otherBlockingOperation() in a Thread, which did not work again.
However I think the real problem is merge which will only update the entity after the method is done. How can I change the values of Object instantly?
Edit:
@PersistanceContext
private EntityManager em;
mergeUser(T entity)
em.merge(entity);
em.flush();
java jpa java-ee java-ee-7
asked Mar 22 at 14:42
greedsingreedsin
386821
I have a @Stateless-Bean which performs some Database operations in a single method
public void doOperation()
User u1 = createNewUser()
User u2 = createNewUser()
User updated = mergeUser(u1,u2) // just as an example
// should write to database now!
otherBlockingOperation()
However the changes are not visible in the database until the blocking operation finished and therefore not visible in the frontend.
I thought this is because the transaction is not committed until otherBlockingOperation() is finished. I then wrapped otherBlockingOperation() in a Thread, which did not work again.
However I think the real problem is merge which will only update the entity after the method is done. How can I change the values of Object instantly?
Edit:
@PersistanceContext
private EntityManager em;
mergeUser(T entity)
em.merge(entity);
em.flush();
java jpa java-ee java-ee-7
java jpa java-ee java-ee-7
asked Mar 22 at 14:42
greedsingreedsin
386821
asked Mar 22 at 14:42
greedsingreedsin
386821
edited Mar 22 at 15:02
greedsin
asked Mar 22 at 14:42
greedsingreedsin
386821
asked Mar 22 at 14:42
greedsingreedsin
386821
asked Mar 22 at 14:42
greedsingreedsin
386821
386821
Please provide the code ofmergeUser, this could be relevant. You are correct on your observation about transactions: In a@Statelessbean, a transaction is started (by default) and DB is updated only after transaction is committed. Even if youentityManager.flush()during the transaction, DB will be updated but still changes will be visible in your transaction only (unless some non-standard isolation level is used)
– Cascader
Mar 22 at 14:47
Also, managing your own threads in a JavaEE app is major no-no. The application server should be the only responsible for thread handling, using JavaEE methodology (i.e.@Asynchronousbusiness methods etc)
– Cascader
Mar 22 at 14:55
add a comment |
Please provide the code ofmergeUser, this could be relevant. You are correct on your observation about transactions: In a@Statelessbean, a transaction is started (by default) and DB is updated only after transaction is committed. Even if youentityManager.flush()during the transaction, DB will be updated but still changes will be visible in your transaction only (unless some non-standard isolation level is used)
– Cascader
Mar 22 at 14:47
Also, managing your own threads in a JavaEE app is major no-no. The application server should be the only responsible for thread handling, using JavaEE methodology (i.e.@Asynchronousbusiness methods etc)
– Cascader
Mar 22 at 14:55
Please provide the code of
mergeUser, this could be relevant. You are correct on your observation about transactions: In a @Stateless bean, a transaction is started (by default) and DB is updated only after transaction is committed. Even if you entityManager.flush() during the transaction, DB will be updated but still changes will be visible in your transaction only (unless some non-standard isolation level is used)– Cascader
Mar 22 at 14:47
Please provide the code of
mergeUser, this could be relevant. You are correct on your observation about transactions: In a @Stateless bean, a transaction is started (by default) and DB is updated only after transaction is committed. Even if you entityManager.flush() during the transaction, DB will be updated but still changes will be visible in your transaction only (unless some non-standard isolation level is used)– Cascader
Mar 22 at 14:47
Also, managing your own threads in a JavaEE app is major no-no. The application server should be the only responsible for thread handling, using JavaEE methodology (i.e.
@Asynchronous business methods etc)– Cascader
Mar 22 at 14:55
Also, managing your own threads in a JavaEE app is major no-no. The application server should be the only responsible for thread handling, using JavaEE methodology (i.e.
@Asynchronous business methods etc)– Cascader
Mar 22 at 14:55
add a comment |
1 Answer
1
active
oldest
votes
Depending on the actual business requirements, a possible solution would be to move the otherBlockingOperation() method to a new @Stateless bean and mark the method as @Asynchronous @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW). This will effectively run the method in a new thread and new transaction. You would simply @Inject the new bean and call the otherBlockingOperation() method.
A new transaction might (or might not) be a valid option, depending on business needs (i.e. the new transaction might fail, while the original transaction might succeed). However, the update will be committed in DB sooner (but still after the original transaction is committed) without dependency on the otherBlockingOperation() process (or even successful commit).
answered Mar 22 at 15:01
CascaderCascader
1,2391224
Works like a charm!
– greedsin
Mar 22 at 15:08
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%2f55302110%2fjpa-changes-on-db-not-written-before-method-finished%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
Depending on the actual business requirements, a possible solution would be to move the otherBlockingOperation() method to a new @Stateless bean and mark the method as @Asynchronous @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW). This will effectively run the method in a new thread and new transaction. You would simply @Inject the new bean and call the otherBlockingOperation() method.
A new transaction might (or might not) be a valid option, depending on business needs (i.e. the new transaction might fail, while the original transaction might succeed). However, the update will be committed in DB sooner (but still after the original transaction is committed) without dependency on the otherBlockingOperation() process (or even successful commit).
answered Mar 22 at 15:01
CascaderCascader
1,2391224
Works like a charm!
– greedsin
Mar 22 at 15:08
add a comment |
Depending on the actual business requirements, a possible solution would be to move the otherBlockingOperation() method to a new @Stateless bean and mark the method as @Asynchronous @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW). This will effectively run the method in a new thread and new transaction. You would simply @Inject the new bean and call the otherBlockingOperation() method.
A new transaction might (or might not) be a valid option, depending on business needs (i.e. the new transaction might fail, while the original transaction might succeed). However, the update will be committed in DB sooner (but still after the original transaction is committed) without dependency on the otherBlockingOperation() process (or even successful commit).
answered Mar 22 at 15:01
CascaderCascader
1,2391224
Works like a charm!
– greedsin
Mar 22 at 15:08
add a comment |
Depending on the actual business requirements, a possible solution would be to move the otherBlockingOperation() method to a new @Stateless bean and mark the method as @Asynchronous @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW). This will effectively run the method in a new thread and new transaction. You would simply @Inject the new bean and call the otherBlockingOperation() method.
A new transaction might (or might not) be a valid option, depending on business needs (i.e. the new transaction might fail, while the original transaction might succeed). However, the update will be committed in DB sooner (but still after the original transaction is committed) without dependency on the otherBlockingOperation() process (or even successful commit).
answered Mar 22 at 15:01
CascaderCascader
1,2391224
Depending on the actual business requirements, a possible solution would be to move the otherBlockingOperation() method to a new @Stateless bean and mark the method as @Asynchronous @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW). This will effectively run the method in a new thread and new transaction. You would simply @Inject the new bean and call the otherBlockingOperation() method.
A new transaction might (or might not) be a valid option, depending on business needs (i.e. the new transaction might fail, while the original transaction might succeed). However, the update will be committed in DB sooner (but still after the original transaction is committed) without dependency on the otherBlockingOperation() process (or even successful commit).
answered Mar 22 at 15:01
CascaderCascader
1,2391224
answered Mar 22 at 15:01
CascaderCascader
1,2391224
answered Mar 22 at 15:01
CascaderCascader
1,2391224
answered Mar 22 at 15:01
CascaderCascader
1,2391224
1,2391224
Works like a charm!
– greedsin
Mar 22 at 15:08
add a comment |
Works like a charm!
– greedsin
Mar 22 at 15:08
Works like a charm!
– greedsin
Mar 22 at 15:08
Works like a charm!
– greedsin
Mar 22 at 15:08
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%2f55302110%2fjpa-changes-on-db-not-written-before-method-finished%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
Please provide the code of
mergeUser, this could be relevant. You are correct on your observation about transactions: In a@Statelessbean, a transaction is started (by default) and DB is updated only after transaction is committed. Even if youentityManager.flush()during the transaction, DB will be updated but still changes will be visible in your transaction only (unless some non-standard isolation level is used)– Cascader
Mar 22 at 14:47
Also, managing your own threads in a JavaEE app is major no-no. The application server should be the only responsible for thread handling, using JavaEE methodology (i.e.
@Asynchronousbusiness methods etc)– Cascader
Mar 22 at 14:55