Web Development Database – JSON vs Foreign Keys

Unless I'm misunderstanding the question, I don't think that this is an appropriate scenario for caching.

Cached data normally has at least one of the following attributes (usually all of them):

• Expensive to retrieve or compute;
• Highly static - may change occasionally but very rarely;
• Non-critical - OK if the requester sees stale data.

It doesn't sound like any of these apply to your situation.

• The query is a simple SELECT, probably TOP N, just an index seek;
• It changes very frequently;
• Your requirements indicate that immediate updates are required.

So why are you caching? Caching isn't a panacea; oftentimes it can actually make performance worse, if the cache memory could be better used for some other purpose.

Databases do their own caching. As long as the DB server has plenty of memory then it may cache the entire table in memory if it's frequently queried; the performance of that will be just as good as your cache if not better.

Some further thoughts/suggestions:

• If stale data is OK, then the simplest solution would be to use a fixed interval (i.e. expiration). This method is used very effectively in hundreds of thousands of sites and systems. You can either force an update on expiration or just wait until it's requested again.

• If you're concerned about conflicts between reads and writes, then (a) don't be, until you've profiled it, and (b) if it really is an issue then instead of trying to cache it, just use a redundant table or a NOLOCK hint.

If you need to invalidate the cache every single time a row is added/changed then you have completely defeated the purpose of an application cache, and are now trying to implement an in-memory database. Please don't do this unless you have an extremely good reason for it.

Since you're using jackson you should take a look at this : https://github.com/FasterXML/jackson-datatype-hibernate

With this module, jackson will not serialize LAZY fields if you didn't initialize them, so you could have LAZY fields on both sides to not have any problems.

If this solution does not suit to your needs (maybe you want some eager). Then instead of use @JsonIgnore use @JsonIgnoreProperties like this :

@Entity
@Table(name = "wine_case")
public class WineCase {
    @Id @GeneratedValue(strategy = GenerationType.AUTO)
    private Integer id;

    @OneToMany(fetch = FetchType.EAGER, cascade = CascadeType.ALL, mappedBy = "wineCase")
    @JsonIngoreProperties("wineCase", allowSetters=true)
    private List<CaseContent> caseContents;
}

@Entity
@Table(name = "case_content")
public class CaseContent {
    @Id @GeneratedValue(strategy = GenerationType.AUTO)
    private Integer id;

    @ManyToOne(fetch = FetchType.EAGER)
    @JoinColumn(name = "wine_case_id", nullable = false)
    @JsonIgnoreProperties("caseContents", allowSetters=true)
    private WineCase wineCase;
}

The properties exclusion will make sure that you don't serialize cycles whereever you start (ie from child or from parent). The allowSetters will allow deserialisation of the properties, only serialisation will ignore the defined properties in the annotation ( the allowSetters/Getters exists since 2.6).

Be aware that there is currently a bug with jsonignoreproperties and lazy objects : https://github.com/FasterXML/jackson-datatype-hibernate/issues/78. Let's hope it'll be fixed for 2.8.