Difference between revisions of "Talk:EclipseLink/DesignDocs/356812"

Latest revision as of 09:01, 8 September 2011

Shaun Smith

1. The name of the feature should be generalized to refer to "external" change events rather than "database" change events. Notification may be coming from an external system via, say JMS, which knows that certain data has been modified (maybe by itself). The database is only one source of external notification.

We already have the RCM cache coordination API that can receive change events from JMS or other sources. This feature is specific to the events come from database changes. I don't think we want to confuse it with RCM. The "database" can refer to the changes being raw database changes, not having to come directly from the database.

James.sutherland.oracle.com 15:57, 6 September 2011 (UTC)

2. Secondary tables, join tables, etc. can be supported through examination of the descriptors. I have done this myself with secondary table.

No, they cannot. With Oracle DCN only the ROWID is given, so there is no way to related the ROWID from a secondary table or relationship to the ID. Secondary table would be possible, but complex, as we would need to select the ROWID from all secondary tables (in selects and after inserts), and index these in the cache as well. Join tables and relationships would not be possible, we would need to select the foreign keys from the related table using the ROWID and then use the foreign keys to determine the ID (which may require another select). This would be very complex and very expensive, so is left for future development.

Note the generic API does not in anyway prevent supporting relationships, it is only not supported for Oracle DCN.

James.sutherland.oracle.com 15:57, 6 September 2011 (UTC)

Gordon Yorke 14:32, 7 September 2011 (UTC)

We should clearly document these restrictions and log warnings when change notified Entities have these mappings.

Agreed. Limitations need to be documented, and a warning should be logged if optimistic locking is not used.

James.sutherland.oracle.com 12:51, 8 September 2011 (UTC)

3. The Oracle database "DCN" feature has been renamed "QCN": Query Change Notification. I'm not sure in what release of Oracle DB this renaming took place.

It was called DCN in 10.2, and the query feature was added in 11g. It supports both DCN and QCN in 11g. In terms of our usage we are using the DCN part, not the query part. Perhaps just rename to Oracle Change Notification?

James.sutherland.oracle.com 15:57, 6 September 2011 (UTC)

Renamed OracleDCNListener, to OracleChangeNotificationListener.

James.sutherland.oracle.com 12:51, 8 September 2011 (UTC)

Considering renaming the interface from DatabaseEventListener to DatabaseChangeNotificationListener. Thoughts? I original used "event" because I thought we might get other types of events in the future other than change events. There are other events, such as server shutting down, that we may wish to make use of in the future.

James.sutherland.oracle.com 13:01, 8 September 2011 (UTC)

4. This feature focuses on invalidation while it may be the case that the updated data for an object(s) is part of the change event. When available, it should be possible to update the cache with the new data rather than invalidate.

The generic API does not prevent other listeners from providing other options. The API is pretty minimal, just an interface and some callbacks. The main work for this feature is to support Oracle DCN.

James.sutherland.oracle.com 15:57, 6 September 2011 (UTC)

Should this be called expiryType (CacheExpiryType) instead of invalidationType (CacheInvalidationType)? The @Cache annotation already has expiry and expiryTimeOfDay elements. I assume this new enum will work in conjunction with those settings? There could be validation if invalidationType was set to Daily and Cache expiry was set instead of expiryTimeOfDay --Karen.moore.oracle.com 17:03, 6 September 2011 (UTC)

Invalidation is a super set of expiry. Expiry means invalidated because of its age. But you can invalidate for other reasons, such as from database change events. The native API policy is called CacheInvalidationPolicy, with Daily, TimeToLive and NoExpiry subclasses, this will add a forth subclass of Database. The DailyCacheInvalidationPolicy has an expiry time. The existing expiry settings will need to be validated with the type, I considered adding a new annotation, but since @Cache already had these settings, decided to keep the configuration in one place.

James.sutherland.oracle.com 17:23, 6 September 2011 (UTC)

Gordon Yorke 14:32, 7 September 2011 (UTC)

From an extensibility perspective adding a new annotation for ChangeNotification or a new @Cache attribute may be better than limiting this to CacheInvalidation. If we do add other forms of change notification in the future it will be confusing to have multiple ways to configure this or bad form to deprecate an Enum element. Also Cache Expiry could be used in combination with Change Notification to work around the limitations (eg, Secondary Tables, Join Tables)

We could add another policy for ChangeNotfication to the descriptor, but I was trying to avoid yet another policy, and thought just a subclass of CacheInvalidationPolicy would be simpler. I also considered adding another option to the cacheSynchronizationType Enum, but thought the two might be used together. Perhaps a new policy would be better, or just a flag in descriptor's CachePolicy, "databaseChangeNotificationType" Enum of None, Invalidate, (possible future options, Refresh, Changes). Thoughts?

James.sutherland.oracle.com 12:51, 8 September 2011 (UTC)

Shaun.smith.oracle.com 19:15, 7 September 2011 (UTC) We have a number of people concerned with the additions to the EclipseLink API coming out of this feature. James, can you review the comments and concerns and perhaps consult with Gordon on how we can keep the API general enough for future extensions and sufficient to support your current concerns and come back with a proposal?

..ok. What are the concerns exactly? This design document the proposal, is it not?.., and this forum the place to discuss the design? I have responded to every comment so far. We can have a design review if there are unresolved issues. But I need to know what those unresolved issues are?

James.sutherland.oracle.com 12:51, 8 September 2011 (UTC)