Fixing Hibernate SerializationException with Byte Array

Fixing a tricky ORA-00001 error in a Spring Boot + Hibernate application taught me an important lesson about how ORM actually works under the hood. Recently, while working on an Account Payable module, I encountered this error: ORA-00001: unique constraint (DRAFT_LEDGC_PK) violated At first glance, it looked like a simple database issue. But the real problem was deeper in the application logic. The system was updating journal entries, but instead of updating existing ledger records, Hibernate was trying to insert new ones with the same primary key. Root cause: While processing ledger entries in a loop, new entity objects were being created every time, even for records that already existed in the database. Since Hibernate treats new objects as fresh inserts, it attempted to insert duplicate primary keys, causing the failure. What fixed it: Instead of blindly creating new objects, I reused existing entities by fetching them from the parent object’s collection and matching them using the composite primary key. If a matching record was found → update it If not → create a new one Key takeaway: Hibernate doesn’t magically know your intent. If you create a new object, it will try to INSERT. If you want UPDATE, you must work with an existing managed entity. This small change fixed the issue and made the update flow much more reliable. Sometimes, the bug is not in the query or database — it's in how we manage entity state. #SpringBoot #Hibernate #Java #BackendDevelopment #Debugging #Learning #Tech

🛑 Stop hardcoding HQL strings in your Java methods! ✔️Let’s be honest: We’ve all seen (or written) "String Soup." 🍜 ✔️You know the drill—massive HQL strings concatenated inside a DAO method, making the code hard to read and even harder to debug. ✔️If you want cleaner, more professional Hibernate code, it's time to master Named Queries. 🤔 What is a Named Query? ✔️Think of a Named Query as a "Pre-compiled Query Constant." ✔️Instead of defining the query logic at the moment you call it, you define it at the Entity level using annotations. ✔️Hibernate then validates these queries the moment your application starts. 🚀 💻 The Example 1️⃣. The "Clean" Definition Define your query once in your Entity class. It stays organized and out of your business logic. @Entity @NamedQueries({ @NamedQuery( name = "Project.findHighPriority", query = "SELECT p FROM Project p WHERE p.status = :status AND p.priority > 5" ) }) public class Project { @Id private Long id; private String status; private Integer priority; } 2️⃣. The Elegant Execution Calling it is a breeze. No strings, no mess. public List<Project> getTopProjects() { return em.createNamedQuery("Project.findHighPriority", Project.class) .setParameter("status", "ACTIVE") .getResultList(); } 🏆 Why this wins: 1️⃣ Readability: Your Repository layer stays focused on execution, not string manipulation. 2️⃣ Performance:Hibernate parses the query once during initialization, not every time it's called. 3️⃣ Type Safety:It encourages a more structured approach to parameter binding. ❓Is it perfect ➡️ Not for everything. If your WHERE clause needs to change dynamically based on 10 different filters, stick to the Criteria API. But for static, standard lookups? Named Queries are king. 👑 ❓How do you handle your persistence layer? 💎 Named Queries 🛠️ Criteria API ⚡ Raw SQL Let’s hear your take in the comments! 👇 #Java #SoftwareEngineering #Hibernate #SpringBoot #Backend #CleanCode #Programming

🔥 N+1 Query Problem in Hibernate (Most Common Performance Killer) What is it? When fetching a list of parent entities, Hibernate fires 1 query for the parent + N extra queries for each child → leading to N+1 queries. Example 🚨 List<User> users = userRepository.findAll(); for (User user : users) { System.out.println(user.getOrders().size()); } 👉 Hibernate does: 1 query → fetch all users N queries → fetch orders for each user Why this is bad? 🐌 Slow performance (DB round trips) 📈 Poor scalability ⚠️ Hidden issue (works fine locally, fails at scale) Solutions ✅ 1. Use JOIN FETCH @Query("SELECT u FROM User u JOIN FETCH u.orders") List<User> findAllUsersWithOrders(); 2. Use EntityGraph @EntityGraph(attributePaths = {"orders"}) List<User> findAll(); 3. Use Batch Fetching spring.jpa.properties.hibernate.default_batch_fetch_size=10 4. Use DTO Projection (🔥 Best for APIs) @Query(""" SELECT new com.app.dto.UserOrderDTO(u.name, o.id) FROM User u JOIN u.orders o """) List<UserOrderDTO> fetchUserOrders(); 👉 Fetch only required fields → avoids N+1 + reduces data load Flow ⚙️ 1️⃣ Fetch users 2️⃣ Access lazy collection 3️⃣ Hibernate triggers extra queries → N+1 problem Result 🎯 Reduced queries → Faster API → Better scalability Rule of Thumb 💡 👉 Always check generated SQL logs when using LAZY relationships 👉 If you are preparing for Java backend interviews, connect & follow - I share short, practical backend concepts regularly. #Java #Hibernate #SpringBoot #BackendDevelopment #Performance #JPA #SoftwareEngineering

One trace. 572,789 spans. 62% of all trace data in a five-minute sample, from a single service. This was a batch processing job. The #OpenTelemetry Java auto-instrumentation agent created a span for every database call inside a loop. The agent does not have a built-in span count cap per trace. It instruments what it finds, and a batch job iterating over hundreds of thousands of records will produce hundreds of thousands of spans. The trace was unusable. No backend renders half a million spans in a waterfall view. The cost was astronomical, and the four largest traces in the sample had no root span metadata, suggesting missing or disconnected parent spans. Most originated from batch or scheduled tasks like `https://lnkd.in/dBWthabm`. This organization runs 3,532 services, all on Java auto-instrumentation v1.33.6. The agent works well for request-response services. It was never designed for uncapped iteration over data. The fix depends on the batch pattern. For jobs that process items independently, use span links instead of parent-child relationships. Each item gets its own trace, linked back to the batch trace. This keeps individual traces small and queryable while preserving the connection to the batch context. For specific instrumentation that generates noise, the agent supports suppression flags. Setting `otel.instrumentation.common.experimental.suppress-messaging-receive-spans=true` eliminates receive spans for messaging consumers. Similar flags exist for JDBC, Redis, and other libraries. Review which instrumentations fire inside your loops and suppress the ones that add volume without insight. Auto-instrumentation assumes your services handle requests. When your workload does not fit that model, you need guardrails. The agent will not set them for you. And about last Friday's quiz: what does `stability: stable` mean for an OpenTelemetry semantic convention attribute? The answer is that it follows semver deprecation rules. A stable attribute is not frozen. It can still be deprecated, but the project must provide a migration path and maintain backward compatibility for a defined period. An `experimental` attribute carries no such guarantee and might be renamed or removed between releases. If you build dashboards or code generation around an experimental attribute, you accept the risk of breakage on upgrade.

A small annotation that many developers overlook: @Transactional(readOnly = true) Does it really matter? Yes — but not in the way most people think. What it actually does: • Hints the persistence provider (e.g., Hibernate) to reduce dirty checking by adjusting flush behavior • Reduces overhead for read-heavy operations • May optimize transaction handling depending on configuration But here’s the catch: It does NOT: • Make queries faster automatically • Strictly prevent write operations at the database level In fact, if entities are modified, changes may still be flushed depending on the persistence context ❌ Real takeaway: Use readOnly = true for: • Pure read operations • High-throughput query services But don’t treat it as a safeguard against writes. Lesson: Framework optimizations are hints — not guarantees. #SpringBoot #Java #Transactions #Hibernate #BackendDevelopment #Microservices #SoftwareEngineering #JavaDeveloper

⚡ Java Performance Tuning: 9 years of lessons in one post. "The code works, so it's fine." This sentence has caused more production outages than bad code. Performance issues I've seen again and again: 🐌 N+1 query problems in JPA/Hibernate → Always check your SQL logs. Always. Use @EntityGraph or JOIN FETCH. 🐌 String concatenation in loops → StringBuilder exists for a reason. Use it. 🐌 Lazy loading triggering outside the session → Understand your fetch strategies before you deploy. 🐌 Synchronized methods on high-throughput paths → Profile first, synchronize only what needs it. 🐌 Object creation inside tight loops → Every `new` inside a loop is a GC candidate. Profile your allocations. My performance workflow: 1️⃣ Measure first — don't guess, profile with JProfiler/VisualVM/async-profiler 2️⃣ Find the hotspot — 80% of issues come from 20% of the code 3️⃣ Fix the bottleneck — not everything around it 4️⃣ Measure again — confirm the improvement "Premature optimization is the root of all evil" — but so is ignoring production metrics. What's the biggest Java performance win you've achieved? 👇 #Java #Performance #SpringBoot #JVM #BackendDevelopment

Was working on a Spring Boot REST API the other day. Everything looked fine entity class, repository, controller all set up. But two fields, createdAt and updatedAt, were coming back null in every response. Spent time checking the constructor, the DTO mapping, the database config. Turns out I just needed two annotations: @CreationTimestamp → auto-sets the time when record is created @UpdateTimestamp → auto-updates the time on every save Two lines. That's it. Hibernate handles everything behind the scenes you don't set these manually. One more thing I'd missed without @JsonFormat, Java's Timestamp serializes weirdly in JSON. Add this and it formats cleanly: @JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss") Small things. But they'll silently break your API if you miss them. #Java #SpringBoot #Backend #LearningInPublic #HibernateJPA

🚀 Evolution of Database Interaction in Java (🔧➡️⚙️➡️🚀) It’s fascinating how the “most natural way” to work with databases has evolved over time 👇 🔹 JDBC You write everything manually—queries, connections, result parsing. Full control, but a lot of boilerplate. 🔹 Hibernate ORM We move to object mapping. Less SQL, more Java objects. Cleaner, but still requires configuration and understanding ORM behavior. 🔹 Spring Boot with JPA Things get easier. Auto-configuration, reduced setup, better integration. Focus shifts more toward business logic. 🔹 Spring Data JPA (Repository methods) 🤯 Now this feels like magic! Define methods → Framework generates queries → Minimal SQL needed. 👉 From writing complex SQL to just defining method names… we’ve come a long way. 💡 But here’s the reality: Every layer matters. Understanding JDBC and SQL makes you a stronger developer—even when using high-level abstractions. 📌 Abstraction reduces effort, but fundamentals build mastery. What’s your preferred way of interacting with databases? 👇 #Java #SpringBoot #JPA #Hibernate #BackendDevelopment #SoftwareEngineering #LearningJourney

HIBERNATE'S HIDDEN TRAP: EAGER VS LAZY LOADING (PART 1) 🛌⚡ In Hibernate, there are two ways to load data, and both of them can kill your performance if you aren't careful. 1. THE EAGER TRAP 🍔 Eager loading is "greedy." It fetches the parent and all related children in one go. Sounds efficient? Until you realize that fetching one User just triggered a massive chain reaction that loaded 500 Orders, 2000 Items, and 5000 Reviews into memory. Your "simple" query just became a memory bomb. 2. THE LAZY TRAP 💤 Lazy loading is "procrastinating." it only fetches the children when you actually ask for them. But if you ask for them inside a loop, you trigger the N+1 problem. One query to fetch the list, and then 100 more queries to fetch the details. 3. THE "DETACHED ENTITY" CRASH 💥 We’ve all seen the LazyInitializationException. This happens when you try to access lazy data after the DB transaction has closed. It’s Hibernate’s way of saying, "You should have asked for this earlier!" In Part 2, I’ll show you how to use Join Fetching to get the best of both worlds. #Hibernate #Java #ORM #DatabasePerformance #BackendDevelopment #SoftwareEngineering #JavaPersistenceAPI #DatabaseDesign #PerformanceTuning #TechTips #CodingLife #SoftwareArchitecture #API #SQL

While debugging a Hibernate issue recently, I came across something interesting 👇 `org.hibernate.ObjectNotFoundException` — a small error with a big lesson. At first glance, it looked like a typical lazy loading problem. But the actual root cause was deeper. 🔍 What was happening? Hibernate created a proxy for a related entity, but when it tried to initialize it, the corresponding row didn’t exist in the database. 👉 In short: The application assumed data integrity, but the database told a different story. ⚠️ The tricky part? The exception wasn’t thrown during query execution. It appeared during debugging when `toString()` was triggered on a proxy object. 💡 Key learnings from this: 🔹 ORM frameworks don’t guarantee data consistency — your database does 🔹 Lazy loading can hide issues until runtime (or even debug time) 🔹 Using Lombok `@ToString` blindly on entities can backfire 🔹 Circular relationships (OneToMany ↔ ManyToOne) can lead to unexpected behavior 🛠 What helped fix it: ✔ Verifying referential integrity at the database level ✔ Avoiding unnecessary eager access during debugging ✔ Restricting `toString()` to only essential fields ✔ Using LEFT JOIN fetch where relationships may be optional 🚀 Takeaway: Most production issues are not about complex logic — they are about mismatches between your assumptions and actual data. Always trust your database more than your ORM. #Java #Hibernate #SpringBoot #BackendDevelopment #Debugging #SoftwareEngineering #Production #ProductionIssues #ErrorHandling