Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Talk:EclipseLink/DesignDocs/356812"
(New page: Shaun: 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,...) |
|||
| Line 2: | Line 2: | ||
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. | 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. | ||
| + | ::[[User:James.sutherland.oracle.com|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. | 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. | ||
| + | ::[[User:James.sutherland.oracle.com|James.sutherland.oracle.com]] 15:57, 6 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. | 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? | ||
| + | ::[[User:James.sutherland.oracle.com|James.sutherland.oracle.com]] 15:57, 6 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. | 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. | ||
| + | ::[[User:James.sutherland.oracle.com|James.sutherland.oracle.com]] 15:57, 6 September 2011 (UTC) | ||
Revision as of 11:57, 6 September 2011
Shaun:
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)
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)
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)