Skip to main content
Jump to: navigation, search



  • @TenantShared seems much too complicated, why would the user ever require multiple tenant ids in the same Entity?
    • Would be better to support the simple case, and allow the user to use AdditionalCriteria if they have more complex requirements.
  • Also, why have the property specified in TenantId and have the nested Column, why not just have a fixed property name "eclipselink.tenant" and have a TenantColumn similar to DiscriminatorColumn?
  • Will need someway to know the type of the TenantId, similar to the DiscriminatorType, or just maybe have a type which is a Class.
  • Instead of changing every buildRow method to specifically include the tenant column it would be nice to have a more generic mechanism, that can be used for other purposes or more advanced tenant requirements. We could add a special mapping to the descriptor that writes to the column, or have some sort of generic ExtensionPolicy or set of policies on the descriptor that have hooks to support Tenants, SoftDeletes, Auditing, History, etc. 15:08, 2 March 2011 (UTC)

  • The requirement for multiple Tenant Ids is that not all tenants may use the same column or that multiple columns represent the tenant id. Additional Criteria would not allow for updating those fields. We may want to change the annotation so that "TenantId" can be used directly and use "TenantShared" as the complex scenario or follow the JPA pattern and use "TenantIds". This would simplify the simple case. :
public class Employee {
public class Employee {
  • Each Tenant should be given their own ServerSession. This should be doable by augmenting the session name or actually updating the code to store the ServerSession by TenantId as well.
Gordon Yorke 16:15, 3 March 2011 (UTC)
  • The default property name must be prefixed with "eclipselink" as all of our persistence unit properties are, ""
  • The example shows passing a cache setting to creating an EntityManager, this is not possible. The cache must be disabled for the whole persistence unit.
  • An admin persistence unit code be build by just removing the tenant-id in a session/descriptor customizer. 13:47, 8 March 2011 (UTC)

  • We should be managing the cache automatically for users. Unless explicitly overridden using a SessionName or disabling of the cache for each unique set of properties a new Session should be created and used.
  • There should be no EntityManager level cache settings. The cache is not managed at the client level, it is managed at the Session configuration level. If EntityManager level configuration of tenants is required then we should find an EMF that corresponds to the properties unless cache has been disabled. Switching of Tenant properties in a live EM should not be allowed.
  • One of the requirements is to support mapped TenantIds but there are no details on how that would be configured. Is it a matter of EclipseLink just detecting the mutliple writable fields, or with TenantId be applied to the mapping?

Gordon Yorke 16:16, 8 March 2011 (UTC)

  • What is the value of the @Multitenant annotation. Would @TenantDescriminator not give the same value. If we need a new type of multitenancy, we could add a new annotation. (same question about the xml values)
  • Have we specified TABLE_PER_TENANT at all? Should this be a future enhancement, or a design feature in this doc? 15:21, 16 March 2011 (UTC)

Another issue is with Container Managed EMs and EMFs (ie. Injection). Properties are defined statically when using injection and updating properties after the injection has occurred has major concurrency implications. Likely we will want to have some sort of callback mechanism that is statically registered and would access the Current Context or a ThreadLocal to provide the Tenant-Id although there may be no guarantee that the injection thread is the calling thread but in practice it should be.

Gordon Yorke 18:12, 30 March 2011 (UTC)


Is the TABLE_PER_TENANT available in EclipseLink 2.3?

Back to the top