Debugging Spring Persistence and JPA Issues Using Lightrun
So many things can fail when dealing with persistence. We can usually inspect the end result but understanding how it “got there” is often challenging. With verbose SQL we might see the actual SQL call, but who generated it and why? They are also often very hard to read and don’t include important information such as the values passed to the prepared query.
This is where Lightrun really shines, it lets you “see” the details in that middle layer: before the data gets into the database or before the data is sent as a response.
For the purpose of this tutorial I’ll use the Pet Clinic demo application. It’s a relatively simple demo which includes REST calls. You can use any code since I won’t rely on anything specific to that demo.
Step 1 – Build the Demo
Open the project directory from the repository in IntelliJ IDEA. Run the Package option in the Maven tool window.
Step 2 – Install Lightrun
If you didn’t do this yet, create a Lightrun account. Download the IDE plugin and set up the agent on your server. I won’t replicate the steps here as they are pretty clear on the website.
You can download the agent into the project directory, then run the app using:
java -agentpath:PATH_TO_AGENT_DIRECTORY/lightrun_agent.so -jar target/spring-petclinic-2.4.5.jarNotice you need to replace PATH_TO_AGENT_DIRECTORY with the right path. Try to avoid shortcuts like ~ which might cause issues.
You can now install the plugin and log in via the IDE.
Step 3 – Place a Snapshot to See The DB Object
We want to see the value of the object in the server before it was sent to the database for storage. In case of a problem this will tell us if the problem was in the storage process or in the web service layer.
Open the OwnerController class and go to line 73 which is in the else block of the processCreationForm() method. It should include the code this.owners.save(owner);
Right click on the line and select Lightrun -> Snapshot:
In the Expression field, add the following code:
owner.getFirstName().equals("Shai")This effectively means the snapshot will only occur for a user whose name is “Shai”. This is important in production systems since you might want data about a specific entry and don’t want noise about every single entry. Notice that this is an optional feature and you can leave the expression blank to grab any request.
Press OK to submit the snapshot and a camera will appear next to the line.
Apply This to your Own Application
This functionality is remarkably useful for validating assumptions in live applications. When you get data corruption it’s often very hard to determine at which point it happened especially if you can’t reproduce this from your machine.
A simple snapshot or log on the server can instantly change the balance completely.
See Also
See more posts in this series:
It’s Really not that Complicated.
You can actually understand what’s going on inside your live applications.