I start with:

and to add a second SubClass2 from another package packageB, which I wish to have a join table for the extended properties. Now in the overall design, it's OK for packageB to depend on packageA, but not the other way around, so I want to keep SubClass2's Hibernate mapping in packageB as well. Therefore, initially I tried, in SubClass2's own mapping file:

(Note: apparently there is some bug in Wordpress that mangles up the opening and closing tags for "joined-subclass". It's properly opened and closed in my actual XML code.)
But Hibernate threw back a NumberFormatException when trying to convert a string discriminator value, "com.packageB.SubClass2", to an integer, apparently due to the fact that the joined-subclass above didn't give a discriminator value in integer, so it defaults to the class FQN. And of course, the <joined-subclass> element can't have a 'discriminator-value' attribute per the DTD.

Now I could probably just get rid of my integer discriminator scheme and use the default class FQNs. But I never thought class FQNs are good candidates for class type discriminator to begin with, because... well, why would I want to have to screw around in the DB running massive SQL updates just because some class is renamed?

So I end up sacrificing a little on the dependency rule front, and basically moved SubClass2's mapping into SuperClass's:

I still can't see why joined-subclass shouldn't have that 'discriminator-value' attribute, though.

This particular problem comes when I try to inject a DAO into a domain object (I know it's some debatable practice, but please just bear me for a moment). So the DO is annotated with @Configurable, its constructor is advised such that, at runtime, after the initialization, the Spring aspect will try to get a reference to the DAO, and sets it into this new DO instance. However, in order to materialize the DAO, which naturally holds a reference to a Hibernate session factory. The session factory needs to be instantiated first - and that, surprisingly, is when I get the "circular bean reference" meltdown.

After one pint of log reading, three shots of source code tracing, and a pinch of hair pulling, this here turns out to be the story: at the session factory initialization time, Hibernate3 needs to know which id value represents an unsaved object. E.g., null, -1, or whatever sensible value depending on the nature of the object and the corresponding table. This value is specified via the 'unsaved-value' attribute in the object mapping., and, as suggested by the reference, can usually be omitted safely, for Hibernate3 is very smart and can actually guess the unsaved-value by instantiating a new instance of the DO, which naturally would be intercepted by Spring and be injected with a DAO reference, which naturally would need a reference to the session factory, which naturally would have to guess what the unsaved-value is....

The solution is easy - just add 'unsaved-value="null"' to the mapping file, to prevent Hibernate from attemping the guess.

Now, I can hear you making some impatient noise - "what's all this inject-DAO-into-DO business?!" Well, I agree it's some debatable practice, but then it's also hardly the point here. I could well have tried to inject a service object into this DO, and the service object could have held a legit reference to some DAO. It would have been the same circular reference, only a larger circle.

So I went on and did a bit research (OK, OK, I really just googled "define: Scalability"), and got these definitions. Let me just quote the first three here:

The ability to scale to support larger or smaller volumes of data and more or less users. The ability to increase or decrease size or capability in cost-effective increments with minimal impact on the unit cost of business and the procurement of additional services. - dmreview.com

The ability and flexibility of an application to meet growth requirements of an organization. - hostqueue.com

The ability to expand a computing solution to support large numbers of users without impacting performance. - primode.com

So scalability is about performance - the capability to handle large volume of traffic, as far as web applications go. It does not have anything to do with "miminal service interruption when one of the servers goes down" - that's High Availability. It especially does not have anything to do with "no service interruption whatsoever" - that's Continuous Availability (see the last link). We usually don't need the expensive state-replicating schemes to achieve Scalability, or even High Availability. A sticky-session load balancer and a server farm without busily replicating sessions among themselves would scale well, and would provide some pretty high availability. It can't provide Continuous Availability because when a server fails all the users on that server at that point would have lost their sessions. That's the only case where clustering comes in and support immediate fail-over without any interruption to the service.

Now, the real question for all you architects out there that can't wait to hop on the "clustering wagon" the second you hear "scalability" is, is your application really "mission-critical" enough, meaning no user can ever lose her session, to justify the cost to implementing clustering? Remember the cost here includes not only the performance penalty (ironic isn't it), but also the development penalties - you'll have to make sure that whatever you stick in the session implements the Serializable interface, that whatever you stick in there references does the same, and finally that not too much is stuck in there.

On a separate level, I don't necessarily agree with Diego's comment (his main point actually) on Spring being not scalable, either. The fallacy here, IMHO, is the same as what I have seen from a lot of other online discussions. It's that people keep trying to compare Spring with EJB, forgetting they are different things and meant for different things.

What is Spring? Even though we all refer to Spring as a container, we have to remember that it's a completely different kind of container from the kind EJB is. Spring is a bean container, or rather more accurately, as the name of one of its core interfaces shows, it is a bean factory. All Spring does is providing us the ability to transparently wire up our applications, and the convenience to easily integrate with lots of third-part tools, but Spring does not reinvent the wheels by reimplementing those tools on itself. E.g., Spring provides easy integration with well-known ORM tools such as Hibernate and iBatis, rather than providing it own ORM package. On the other hand, EJB is a container in the real sense of "All Your Base Are Belong To Us" . It provides a complete solution with a more restrictive programming paradiam. Spring is not mutually exclusive with EJB, nor is it a competitor of the latter one. You can use Spring to wire up an EJB-based service layer just as easy as you do, say, a Hessian-based one. Comparing Spring to EJB is like comparing apple and orange.

So here are the pros of property access I can think of:

• It conforms to the OO encapsulation principle. This is also the reason that property access is the preferred strategy by the Hibernate team (as discussed in Hibernate In Action and implied by it being the default accessing strategy in mapping file definitions).
• It provides a subclass the possibility to override a property accessor.
• Field access assumes a SecurityManager not restricting access to private instance variables. In most of cases this is a valid assumption - if an application needs to worry about others running in the same JVM peeking into its private fields, it should probably get its own JVM. But still, property access does not have this kind of restriction.

Now the pros of field access:

• Field access allows to bypass an accessor that has more logic in it than simple value getting/setting. If we want to achieve direct mapping between database and domain objects (rather than DTOs), this can be very useful because most of the time the extra logic added is business logic, and should not or need not be applied at persistence time.
• Field access eliminates the need to define an accessor that does not make sense in the domain model, but just for the sake of populating the field at persistence time. The most typical example is the primary key field in every "Hibernated" objects, which usually should never be changed through out the object's lifetime. From the architecture standpoint, this is also a strong argument for the field access approach because it prevents the leakage of concerns from the data access layer into the domain model.