Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 days ago.
Improve this question
Some methods in the transaction successfully call the interface, but in the end the transaction fails, resulting in a rollback, resulting in inconsistent data between the interface side and the local place
For example：
"pickTicketList" is the transaction you want to ship,but one of the "pickTicket" has an exception, causing the transaction to roll back
#Override
#Transactional
public void shipBol(WmsMasterBOL masterBol) {
for (WmsPickTicket pickTicket : pickTicketList) {
wmsPickticketManager.ship(pickTicket);
}
}
But the first few "pickTickets" have already called the sendMessageByI10() method. How can I keep the data of the client calling the interface and the local data consistently?
#Transactional
#Override
public DtWms0010Res prdoDeliv(WmsPickTicket pt){
DtWms0010Res resp = this.sendMessageByI10(outLog.getId());
return resp;
}
What are the ways to solve this problem
I am writing over as my understanding based on questions.
This is related to transaction propagation like: you need to mention transaction on methods as per reuqiredment.
Propagation
#Transactional(propagation=Propagation.Required) like this.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed last month.
Improve this question
I have a Spring Boot application connected to a PostgreSQL database.
This server will be receiving HTTP requests such as POST from another software to store some statistics, but I want to avoid having to undergo the process of acquiring all of those statistics again if an entry that matches some of the identifiers that the statistics has already exists in the database.
How can I do this check from the software-side, instead of server-side?
That is, without an usual GET method, because that will possibly return a very large list, to the point where it becomes too expensive to find a matching entry and to make this check in the application.
I hope I understood you correctly!
There are several options to launch some functionality without waiting for external requests.
One option is to use the #Scheduled functionality of spring
#Configuration
#EnableScheduling
public class SpringConfig {
...
}
#Scheduled(fixedDelay = 1000)
public void scheduleFixedDelayTask() {
daoSevice.execute();
}
https://www.baeldung.com/spring-scheduled-tasks
Good luck!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Many methods in my code I am currently working on follows a certain pattern:
public void aMethod(...) throws CustomException {
Log("aMethod Started")
try {
//Many method calls that could throw a CustomException
} finally {
Log("aMethod Ended")
}
}
Changing anything about the CustomException is not an option.
Is there any better alternative that doesn't work with try finally?
I would say
finally {
Log("aMethod Ended")
}
is not good way to log ending of method.
If an exception occurred the method has not actually ended but interrupted and returned without completing.
So, the "Log("aMethod Ended")" shall be outside of finally. If end logger is missing in that log, you will anyway get from the exception stack trace.
If you want to just log weather the method was called and then left, then Spring AOP is what could be implemented for the whole product configuration, so you wont need to duplicate the logger everywhere.
On the other hand, if you personally feel this logger wont be of much use and just redundant information; then just turn off that rule in solar lint configuration.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I am implementing a DELETE rest endpoint in spring boot, I am not sure which approach is better between below 2 approaches:
First checking if the record with given Id exists in the database and then delete it safely.
Directly calling delete on spring data repository and catching EmptyResultDataAccessException thrown by spring data to return 404 response.
I like the first one as the code is more readable and does not involve controlling flow using exceptions. However, it involves an additional call to db and potential race condition.
Why would you prefer the first or the second approach?
If you annotate the service method with #Transactional there will be no race condition and it's fine to check for existence first (with a small performance overhead).
On the other hand I always like the simplicity of attempting the deletion and catching the exception, the assumption being that deleting a non-existent resource is exceptional.
Note also that in REST a DELETE on a non-existing resource should normally return a succesful HTTP status code 200 (OK) or 204 (NO_CONTENT).
#Transactional
public Response deleteAfterChecking(Thing thing) {
if (!repository.exists(thing)) {
repository.delete(thing);
}
return Response.NO_CONTENT;
}
public Response deleteHandlingException(Thing thing) {
try {
repository.delete(thing);
}
catch (NotFoundException e) {
// do nothing
}
return Response.NO_CONTENT;
}
The first option is better conventions-wise and will be more readable, but not performance-wise on big amounts of data as you will need two calls. Indeed, you should not need to catch an EmptyResultDataAccessException at any point.
You should nonetheless think about your code conception. How can the ID of a potentially non-persisted object be passed ? Is it necessary ? Without your code, I can't judge, but I believe you should consider this.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I've seen that programmers use two different ways to update entity:
First method is to make service update method transactional and using hibernate dirty checking. This is simple update and User class doesn't contains any lazy collections.
#Transactional
public void updateUser(Long id, String name) {
User user = userRepository.find(id);
user.update(name);
}
Second way use method save from spring-data.
public void updateUser(Long id, String name) {
User user = userRepository.find(id);
user.update(name);
userRepository.save(user);
}
Which way should I use for that simple update?
If you modify an object that is known by the hibernate session, it will automatically be saved by hibernate when session is flushed.
I would advise against this because in your code you don't know if you are using hibernate or another ORM. Additionally, if your object is not in the session when you modify it, it will not be saved. So always call save explicitely to make sure your object is saved.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I have validator validating, for instance, input data. It gets object product (class Product) created with default constructor. One of Product fields is description, and it has #NotNull annotation.
When I run test it fails obviously and shows NullPointerException. I can surround part of code where NullPointerException was thrown with if-else like this
if(description!=null){
// product validation
}else{
errors.rejectValue("description", errorCode, defaultMessage);
}
That works, but i need something else, maybe using annotations.
You con use something like Mockito to create a mock of the BindingResult that has a method hasErrors() to check for any errors.
See more solutions...