Caching with Relationships

I want to completely disable caching - I know this will be a performance hit but our table sizes are small and we’ll re-enable the caching once we configure the TCP Notification Server and have tested it in our environment/ with redundancy etc.

So, to disable the caching I set cacheType = none as follows and sure enough I see all application finds going to the db (sql logs and profiler show that)

 <MithraObjectConfiguration
  className="com.greenhedges.Account" cacheType="none"/>

 <MithraObjectConfiguration
  className="com.greenhedges.AccountAgreement" cacheType="none"/>

My issue is the one-to-many relationship are not refetched/queried from the db each time - e.g. say an Account can have n number of AccountAgreements:

<MithraObject objectType="transactional">
<PackageName>com.greenhedges</PackageName>
    <ClassName>Account</ClassName>
    <DefaultTable>account</DefaultTable>
...
    <Relationship name="aggreements" relatedObject="AccountAgreement" cardinality="one-to-many" relatedIsDependent="true">
         AccountAgreement.id = this.id
    </Relationship>
</MithraObject>

Is there a way to force the relatedObjects to be reloaded always?

[mohrezaei]

Eager graph loading in Reladomo is done via deep fetch on the list object, which means you can’t really use the findByPrimaryKey convenience method if you want to load a graph eagerly. It’s not hard to use a list even if you want to load one object with some of its graph:

AccountList accountList = AccountFinder.findMany(someOp);
accountList.deepFetch(AccountFinder.agreements());
Account a = accountList.get(0);

When you use the list to eagerly fetch part of the graph, you’re effectively forcing a refresh in scenarios where the data may have changed in the db.

Deep fetching is always local to the piece of code: there is no way to globally change the behavior of calling a find (e.g. always forcing a certain relationship to be loaded eagerly). We believe forced graph loading in all contexts is an anti-pattern.

Most of the time, when you want to use a single object, there is no difference between eager and lazy loading with some exceptions:

• A traversal through a to-many relationship to another deeper object.
• Db changing without notification.

Just to complete the picture, when you have an account object (regardless of whether you got it from a list with a deep fetch or findByPrimaryKey), a relationship traversal (calling account.getAgreements()) will hit the cache if it can, and then the database if it must. In other words, relationships will lazily fetch data from the database if they must, but they are not affected by the cacheType="none" configuration (because then the piece of code I pasted would do very bad things). Another way to think about this is that the eager fetching via deep fetch is just priming the cache, not sewing a graph.

As you’ve said, transactions don’t trust the cache at all, until they load something in that transaction from the database (which is really part of the locking scheme, with data refresh as a side effect). As far as eager/lazy fetching, the transactional context doesn’t make a difference (other than knowing when the cache is trustworthy).

A lot of this behavior is also predicated by the “uniquing” feature of Reladomo: each persistent object, identified by its PK, is guaranteed to have reference stability across the JVM.

[mohrezaei]

Whether using a microservices architecture or not, you should think of your domain as a singular, coherent API. That means defining your domain in one place. Avoid defining the same thing in multiple places and avoid splitting your domain (especially where you’d be breaking natural relationships).

Your services can then use that consistent domain to serve their logic.

From a topology perspective, think of the domain as a single jar that you deploy to all your instances/services and have a single notification server for that cluster of services that use the same objects.