Benefits of Dependency Injection

This question is often asked at interviews, and a good list of reasons to use it can be found at http://anandmanisankar.com/posts/angularjs-dependency-injection-demystified/:

• Separate the process of creation and consumption of dependencies
• Let the consumer worry only about how to use the dependency, and leave the process of creation of the dependency to somebody else
• Allow concurrent/independent development of the dependency and the dependent entity, while only maintaing a known contract
• Facilitate changing of the dependencies when needed
• Allow injecting mock objects as dependencies for testing, by maintaining the agreed contract

Use of "Requires New" Transaction in Chunk Processing

One place to use @Transaction "requires new" is on the onXXXError listener methods (or on methods called from them) that fire on error events during chunk processing in Spring Batch because the current transaction might be rolled back (depending on any no-rollback-exceptions set):

With annotation based transaction handling you can put the annotation @Transactional(propagation=Propagation.REQUIRES_NEW) on the method to achieve this.

https://blog.codecentric.de/en/2012/03/transactions-in-spring-batch-part-2-restart-cursor-based-reading-and-listeners/

Configuring Drools Rules Precedence

See how: http://blog.athico.com/2014/04/exercise-1-public-training-san.html

On LazyInitializationException - Example

Example given here: http://grails.github.io/grails-doc/2.3.11/guide/services.html

Review how it's possible to get this exception if a Hibernate session is closed via transaction rollback but the exception carries a pointer to the non-greedy loaded object. In the catch clause if the object's children are accessed a LazyInitializationException is thrown because the object is detached and it's lazy-loaded children are uninitialized.

Useful Custom Exceptions

One useful custom exception to cite as an example of "when would you use a custom exception" interview question is the ObjectNotFoundException triggered when accessing an invalid proxy gotten from the session.load() method. Custom exceptions are useful to for conditional logic that is strongly typed and semantically precise and, moreover, more natural then parsing and identifying error codes or String value properties of more generic exception types.

Hibernate's inverse=true on sets, and cascade=all

review this example: http://www.mkyong.com/hibernate/inverse-true-example-and-explanation/

upshot: makes more sense to do inverse=true -- results in fewer SQL statements.

But what if you just want a many-to-one relationship? e.g. a Rectangle that has a instance variable of type Point and Point can be a property of multiple Rectangles. Furthermore, you only need this to be unidirectional. No need to navigate from Point to Rectangles. (Note: a rectangle's location be defined by a single point.) In this case inverse="true" won't help because it can only be applied to a collection not a property. So what if you want to persist the Rectangle with one Hibernate save statement, and not have to first save the point, then save the rectangle to avoid a referential integrity error. The trick was mentioned in passing here: using cascade="all" on the many-to-one element in the unidirectional relationship's only side, in this case Rectangle, or if using annotations @ManyToOne(cascade=CascadeType.ALL) -- with cascade set to all, " if we perform an insert on the child row, Hibernate will automatically create the parent row based on where the child row is pointing." THAT saves a line of code, which can be a HUGE benefit especially if this is a polymorphic Hibernate util, otherwise, you would have to do something like either cast the entity to see if it's a Rectangle and has a point or in which case persist the Point or create a "performPreSave(session)" which is called on all entities where a Rectangle could override and persist its Point. Hacky! So...use cascade="all"...

Update. Rather than cascade="all" to achieve this single-save-cascade effect, should use "save-update" because you don't want to cascade a delete probably ever, if it's a many-to-one, since there could be other shapes like polygon relating to that point and possibly even other rectangles. In fact, cascade delete would probably only ever make sense in a one-to-one, and only ever in a one-to-many if the many-side table (the table holding the foreign key to the one-side table) did not contain foreign key references / relations to other entities. Answer here referencing Hibernate docs agrees with this.

This save-update effect would be useful to the afore-mentioned unidirectional relationship for the purposes of adding the related records upon saving the primary record, in this case the rectangle.

Observable: Reason for setChanged()

This is useful because it separates the part where you say that the Observable has changed, from the part where you notify the changes. (E.g. Its useful if you have multiple changes happening and you only want to notify at the end of the process rather than at each small step). This is done through setChanged().

- jbx http://stackoverflow.com/questions/13744450/interview-when-do-we-use-observer-and-observable

 ...setChanged is used like a flag I think. This is to avoid unnecessary updating

- James Poulson http://stackoverflow.com/questions/7271044/observable-in-java

But note possible race condition in Java's implementation of Observable where a second call to notifyObservers may not be completed and thus second parameter (if one is provided) is not sent. See answer by mab at http://stackoverflow.com/questions/4446718/why-observable-snapshot-observer-vector/11122611#11122611.