See attachments for whiteboard photos and audio of meeting discussion.
Some topics discussed - questions to answer:
- Ways in which this service co-exists with other services in the Services Layer.
- Tenant-based usage.
- Tenant context at start-up and shutdown.
- Whether the schemas for CollectionObject, etc., are correct with ID Service usage.
- Where binding occurs.
- How service is configured.
- How ID generators are associated with other services; what type of context?
- Migration from one server to another. (Follow-up: And one tenant to another? Which ID generator instances may be shared and which are exclusive to a single tenant?)
- If plan to cache state, how data is reinitialized on restart.
- How to deal with data sent in responses that doesn't reach the requestor (e.g. due to network errors, requestor going away).
- Write response on a stream, then write when confirmation? Possible conclusion: may be overkill .
- How to deal with rapid, near-simultaneous, possibly overlapping requests. (E.g. Non-safe requests, such as creates.)
- IDResource as singleton class.
- Use SELECT FOR UPDATE, supported by all major databases.
- (Discussion of lock period, even a short one, with pros and cons ...)
Database table schemas
ID Service binding
- Tenant ID
- ID Generator ID
- Text (e.g. tag or equivalent)
ID Generator definitions
- Display name
- ID (can even be simple integers)
- Parts (can be normalized into their own table)
- Display name
For Further Discussion
Other table schemas
- ID Part values
- Tracking of IDs within a deployed system
JIRAs to add
- Move hard-coding of database configuration for ID Service to external configuration. (Where feasible, share at least part of this configuration with common services layer configuration.)