Hi, Both the EJB 1.1 and the EJB 2.0 PFD1 specs suggested that entity objects should be coarse-grained, and gave three reasons (see e.g. EJB 1.1 section 9.1.2 and EJB 2.0 PFD1 section 9.3.1): 1. The cost of pass-by-value semantics, and potentially the cost of a remote call, between components. 2. The cost to check security. 3. The cost to apply declarative transaction attributes. In EJB 2.0 PFD1, the concept of "dependent object classes" allowed these coarse-grained components to be modeled using Java classes that were visible to, and managed by, the container. (This is as opposed to "dependent value classes," that are not visible to, nor managed by, the container.) These dependent object classes did not incur the costs of pass-by-value semantics, remote calls, security checks, or the application of transaction attributes. The EJB 2.0 PFD2 specification suggests that local objects are appropriate for modeling fine-grained objects. (See, for example, EJB 2.0 PFD2 section 4.1.2.) This is because local objects do not incur the costs of number 1 above (pass-by-value semantics or a remote call). They do, however, incur the costs of numbers 2 and 3 (checking of security attributes and application of transaction attributes). My question is simply: is consideration of this overhead significant in designing your object model? I am imagining a scenario where attribute "get" and "set" methods are exposed in a local component interface, for an entity intended to represent a fine- grained element of an object model. These "get" and "set" methods might be used quite frequently in the application's business logic, and each invocation would incur that overhead. Or has experience shown that checking security and transaction attributes is a neglible part of the container's total work, or highly amenable to container optimization? I ask this because I can't find in EJB 2.0 PFD2 a statement about the cost of checking security and applying transaction attributes, even though previous versions and drafts make this point. -Dan =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
