SAP EJB 3.0/JPA Entity caching?

[former_member189576]

I know some JPA-based persistence frameworks (such as Toplink) transparantly provide entity caching to avoid database queries, but I haven't been able to find any documentation regarding SAP's implementation of JPA.

Can anyone tell me if it supports entity object caching?

If so, can you point me towards some documentation regarding it?

Thanks.

[Former Member · Accepted solution]

Hi, Derek,

Check this out:

http://help.sap.com/saphelp_nwce10/helpdata/en/47/12ba1cd9ed584a957e5cf6bf243625/frameset.htm

Regards,

Yordan

[former_member189576 · Accepted solution]

Thanks for the link Yordan.

I also found a [pdf that describes the table buffer|http://www.sap-press.de/download/dateien/259/sap_press_pog_007.pdf]. Unfortunately it seems it has quite a few limitations that may preclude it from providing a comprehensive JPA caching solution:

The following SQL statements do not access the SAP buffer:
SQL statements with the clause BYPASSING BUFFER. This clause is
used to indicate statements that should deliberately not access the
buffer.
SELECT FOR UPDATE statements. These statements set a database
lock and as a result they involve a database access.
SQL statements using the aggregate functions SUM, AVG, MIN, MAX
SQL statements with SELECT DISTINCT
SQL statements containing the operator IS NULL
SQL statements that trigger sorts (except sorts by primary key)
SQL statements that access views (except projection views)
Native SQL statements

Since the JPA implementation forms its own queries based on JPQL you have little control over the sql statements, plus the sort (order by) restriction on any fields other than the PK is quite limiting.

Am I correct in assuming that outside of the table buffer option there is no implicit caching in the SAP JPA implementation?

Thanks.

[adrian_goerler · Accepted solution]

Hi Derek,

you are right. SAP JPA currently offers no automatic object-level cache. Also, no third party cache is plugable.

At the time being, the only caching solution we are offering is the Table Buffer, which caches in terms of database-rows.

Using the table buffer in conjunction with SAP JPA has some pros and cons.

On the one hand, the table buffer is a proven technology, well integrated into SAPs Java Persistence Framework. It is queryable (with the before mentioned limitations), transactional, clusterwide synchronized and monitorable, supports prefetching.

On the other hand, the table buffer is limited to certain uses cases, where the tables to be cached are fairly small and mostly read and rarely written. And, most importantly, the table is designed for being read with the leading primary key columns specified. Also, the table buffer requires using Open SQL for Java.

The SQL statements SAP JPA generates for basic load/store/navigation operations are table-buffer-friendly, in general. To which extend queries can be executed in the table buffer or will bypass it depends largely on the original JPQL query. Overall, the table-buffer actually works quite well with SAP JPA.

This means that no general recommendation can be given to use the table buffer. Whether the table buffer is usable for certain tables of a given application depends largely on the distribution of read/write accesses on this table . A good starting point for an analysis of the database accesses are the [Open SQL Monitors|http://help.sap.com/saphelp_nwce10/helpdata/en/45/38332ec4eb3446e10000000a155369/frameset.htm].

I hope this helps,

Adrian