This should be added alongside the existing in-memory cache in OcspCtSctListExtension.
When a SCT is not present in the in-memory cache, we should check if it is present in the persistent SCT table (and only if not present there, we should submit to the CT log). If the data was found from from the table, it should now also be placed into the cache (entry.setValue)
This will require passing some object with callbacks that does the database read, because OcspCtSctListExtension cannot call session beans (that do the database reads). Re-use the callback object in ECA-8134, if that issue is implemented first. See CTAuditLogCallback for an example object.
Update: OcspCtSctListExtension can in fact call session beans, so there is no need for a callback class. Just call the session directly.
Update 2: The OcspCtSctListExtension does in-memory caching on the whole "SCT List extension", so this is not the same as the individual SCTs. We should consider creating a new issue to restructure the existing code, so it caches individual SCTs also. This would require changes in CertificateTransparencyImpl.
Update 3: The OcspCtSctListExtension does in-memory caching on the whole "SCT List extension", so this is not the same as the individual SCTs. We add a callback that is called from CtSubmission.doFetchSct (it can not call EJBs directly), that checks if we actually need to fetch the SCT or if it is already present in the cache. The callback object could possibly be the SctDataSession itself, or it could be some kind of "middle layer".