Pedro Kowalski wrote:
What is the relation between the ENC and JNDI? Is ENC a JNDI, is it a part of the JNDI or are these two entities unrelated with each other?
Pedro Kowalski wrote:
Are the ENC parameters read only during deployment and CAN'T be changed at all after the deploy? I just was wandering that if it WOULD be possible to change the ENC value, you might end in an inconsistent EJB state.
But what about Application Managed Entity Manager. Can't they also be transaction scoped or extended scoped? Correct me if I'm wrong!
Jehan Jaleel wrote:
In other words how can I ensure that Hibernate will only update the one column which changed rather than trying to persist the entire object?
save() and persist() result in an SQL INSERT, delete() in an SQL DELETE and update() or merge() in an SQL UPDATE. Changes to persistent instances are detected at flush time and also result in an SQL UPDATE. saveOrUpdate() and replicate() result in either an INSERT or an UPDATE.
Kengkaj Sathianpantarit wrote:
EJB 3 promotes the use of JPA in which JPA Entities are POJOs, therefore displaying 100 objects in View Layer result in zero remote call. Applying "Transfer Object" in this case doesn't help anything but introduce duplicate classes.
Kengkaj Sathianpantarit wrote:However in some cases we can create "Value Objects" [DDD, Fowler], which is totally different from "Transfer Objects".
Calling entity bean methods directly circumvents the business logic contained in session beans, and tends to push the business logic into the UI code. Session beans can protect the UI from changes to the entity beans. Restricting client access to session beans conserves server and network resources.