XYZApplication
>>src
>>WebContent
>>>>META-INF
>>>>WEB-INF
gradle.build (placed under XYZApplication)
gradle.properties (placed under XYZApplication)
XYZApplicationEAR
(the parent ear project that contains web nodule XYZApplication)
Tim Holloway wrote:
If you persist or merge data in method A, the changes should appear in the context of method B as long as you are using JPA properly. That is, you retrieve data in method B using the same persistence manager, you retrieve it after it was persisted (don't use out of date objects), and you don't forcibly fetch directly from the database.
quote]
I get what you mean but problem is, method B is a web service. Method A is a dao method in the current application.
The option of transferring or copying Method A's logic in Method B is not viable because of that design principle of Cohesion - a web service in our system should have a single, well-focused purpose. Method B is also reused by other systems.
OR you can have method B run as an independent transaction
Roel De Nijs wrote:
Andres Delrotti wrote:I hope this would just be simple enough to convert. I'm just new to JPA, specifically JPQL and we wanted to convert this query.
As you are new to JPA, you need a very good resource to refer to if you have doubts, questions and/or looking for some sample code (snippets). The Java Persistence API WikiBook is an excellent resource and when I'm having an issue with JPA, JPQL, or something related it's the first resource I'll check to find a solution. It's really awesome!
I would suggest having a look at several sections of this book: entity mappings, relationships, JPQL query,... and you'll probably discover yourself how this fairly simple query can be converted to JPQL.
Hope it helps!
Kind regards,
Roel
Bear Bibeault wrote:
If the dropdowns do contain sensitive data that needs protecting, making additional calls makes no sense. Simply return a response status code that indicates a security timeout from the Ajax requests that return the options data.
Stefan Evans wrote:
How do you deal with a session timeout in the general case?
- alert the user, and close the app?
- ask them to log in again (retaining current context or not?)
Bear Bibeault wrote:Don't pass those requests through the filter.