Local Cache - local reads vs remote during an active transaction

Hello,

If we are using a local cache in write method that has an active Transaction, will a read done thru the local cache be local or remote? In this case, the object being written is in a different gigaspace. The local cache is on another gigaspace that just contains static used as reference data. That data is hardly ever changed but is read a different points for other purposes in this write method.

The documentation is a bit confusing to us because even though the read isn't transactional, there is an active transaction because the method called is annotated with @Transactional. What we are unclear about is will that read be remote or local against the cache. We know if this was a view, we would get an error message about not reading views within a transaction. We think this might be a performance issue for us because we thought the read would be local to the cache but behind the scenes it was actually doing a remote read each time even on objects we aren't writing.

Thanks

Rich

https://docs.gigaspaces.com/xap/12.1/...

Transactional Operations Transactional operations are always executed on the master space.

asked 2017-06-15 07:06:57 -0500

rich
1 ●14 ●17 ●18

edit retag flag offensive close merge delete

add a comment

3 Answers

Sort by » oldest newest most voted

Per documentation, the local cache is created empty, and whenever the client application executes a query the local cache first tries to fulfill it from the cache, otherwise it executes it on the master space and caches the result locally for future queries. I don't see how transactional behavior is influencing the cache behavior. Do you mind providing an example?

answered 2017-06-20 08:17:54 -0500

Dixson Huie

81 ●1 ●4

edit flag offensive delete link

Comments

Hi Dixson,

What I am really looking for is a clarification in the document. Please see the post above for the link but please provide more detail with the statement

Transactional Operations Transactional operations are always executed on the master space.

So is that true for reads? For example, if I am just doing say a committed read by id and there is an active Spring transaction is it done on the cache or the remote space (assuming the object is in the cache)

Rich

rich ( 2017-06-20 08:25:57 -0500 )edit

add a comment

Hi Rich,

When the read is done under from transaction it reads from the master space.

In pseudo code:

if( object not under transaction )  
>>read from localcache
>>if( object returned is not null )
>>>>return this object

read from masterspace
if( object returned is not null )
>>update cache

answered 2017-06-22 09:42:20 -0500

Dixson Huie

81 ●1 ●4

updated 2017-06-22 09:45:20 -0500

edit flag offensive delete link

Comments

Hi Dixson,

Ok can you explain to me why? Why if I am doing say a dirty read or even a committed read this has to go back to the remote space? These don't have to be rolled back so at this point to me the difference between a view and cache is pointless. A view will at least fail if I am under a transaction where a cache has this silent performance killer where it ends up doing a remote read when you assume it is a normal cache read (assuming the object is in the cache). So now I am really confused on best practices for using a view vs a cache. I just don't understand why I would use one vs the other.

Rich

rich ( 2017-06-22 10:08:42 -0500 )edit

The difference between localview and localcache is that localview is initialized with all requested data, and is constantly getting updated by a replication mechanism, it is read-only data that reflects remote space data, and all calls done using a localview proxy will not go to the remote space and will return only what is currently in the view. On the other hand, the localcache's contract is to go actively to the remote space and read from there when an object is not in cache or when transactions are used. In addition you can do update or take and we will also go to remote space to do it. Also the localcache is updated according to update policy. See:https://docs.gigaspaces.com/xap/12.1/dev-java/local-cache.html
There is no point in doing a dirty read or read committed against the localcache since all transactions are in the remote space. In other words, when using a transaction, the data needed will not be in the localcache. In the space, when a transaction takes place, we hold both the original and current transaction value. In the case of dirty read we can pick and see what is currently the uncommitted value, this is not relevant for local cache.
The common use case for transactions is to support ACID operations on the objects, the local cache should reflect what we have in the space, and we decided not to support distributed transactions to allow using transactions with the local cache to keep it simple.

Dixson Huie ( 2017-06-29 14:51:00 -0500 )edit

add a comment

Hey Dixson,

Ok thanks for the explanation. I think i understand the complexity of the problem and why this works this way. We are tagging methods with @Transactional(propagation=Propagation.NOT_SUPPORTED) on methods where this is an issue and this seems to be working in the right context where Spring picks up the annotation correctly.

Rich

answered 2017-06-30 07:45:08 -0500