Yes it can, and it's a fundamental characteristic of some of my more complex web applications.
In fact, I have 2 separate layers with @Transactional classes in them: the business persistence layer (services) and the primitive persistence layer (DAOs).
My DAO layer is mostly one DAO class per @Entity (database table) with occasional exections for the tighter parent-child relations. The DAOs are almost exclusively basic CRUD functions.
My Service layer contains the business logic where different types of Entities interact. Typically there's a "working set" tree of related Entities that I deal with here. My higher-level business and GUI functions deal with detached working sets. In the Service layer, they become attached and persisted. The @Transactional nature of the Service layer functions ensures that the entire working set is handled as an atomic
unit. The DAOs are also @Transactional, but for consistency's sake, they are rarely called directly by anything higher than the service level (keeps me from having to hunt through multiple layers). Since I'm using accumulative transactions, all the DAO transactions are performed as part of their service-level transactions.
I also use the @Repository annotation on both DAO and service classes, as that facilitates auto-wiring them.