Here goes Peter, We'll focus in on the "User" model which is easy for everyone to wrap their head around. Most systems have some form of user representation.
The entities are defined in HBM files. Here is the User entity definition: https://github.com/liferay/liferay-portal/blob/master/portal-impl/src/META-INF/portal-hbm.xml#L1002 The Hibernate configuration properties are passed via portal.properties files: https://github.com/liferay/liferay-portal/blob/master/portal-impl/src/portal.properties#L864 But spring is used to control the hibernate configuration and connect the DataSource and TransactionManager: https://github.com/liferay/liferay-portal/blob/master/portal-impl/src/META-INF/hibernate-spring.xml#L20 2nd level caching is provided via ehcache by default (we support other providers as well): https://github.com/liferay/liferay-portal/blob/master/portal-impl/src/ehcache/hibernate-clustered.xml#L62 Next, we have the DAO tier. This is generated code which handles all the mundane, low level persistence work, including a third "generation" cache (I don't want to call it 3rd level since it's integrated with 2nd level cache adding query criteria at both the entity level and result set level). Let's focus on two main use cases, fetching by primary key: https://github.com/rotty3000/liferay-portal/blob/master/portal-impl/src/com/liferay/portal/service/persistence/UserPersistenceImpl.java#L7230 and fetching a result set: https://github.com/rotty3000/liferay-portal/blob/master/portal-impl/src/com/liferay/portal/service/persistence/UserPersistenceImpl.java#L1255 The pseudo logic of each is similar: result = cache.get(params) if (result == null) { session = getSession() query = session.buildQuery(params) result = query.invoke() cache.put(params, result) } return result Finally, a typical usage is: User user = userPersistence.findByPrimaryKey(userId); where the persistence has been wired into some dependent. There is also customization of queries which cannot be "generated" off of semantically defined criteria. The Liferay term for these are "custom finders": An example might be trying to find users by some hard to define relation ( findByNoAnnouncementsDeliveries): https://github.com/rotty3000/liferay-portal/blob/master/portal-impl/src/com/liferay/portal/service/persistence/UserFinderImpl.java#L462 This method references a defined query stored in a configuration file: https://github.com/rotty3000/liferay-portal/blob/master/portal-impl/src/custom-sql/portal.xml#L1376 The query is either an SQL or an HQL query and the developer decides which session method should be used in their custom finder class based on the dialect they wrote the query (in this case SQL92): session = openSession(); String sql = CustomSQLUtil.get(FIND_BY_NO_ANNOUNCEMENTS_DELIVERIES); SQLQuery q = session.createSQLQuery(sql); q.addEntity("User_", UserImpl.class); QueryPos qPos = QueryPos.getInstance(q); qPos.add(type); return q.list(true); Throughout, transaction management is provided using APO define via spring: persistence bean definition: https://github.com/rotty3000/liferay-portal/blob/master/portal-impl/src/META-INF/portal-spring.xml#L158 AOP definition for the "advice": https://github.com/rotty3000/liferay-portal/blob/master/portal-impl/src/META-INF/base-spring.xml#L70 with which are "services" are wrapped. Our advice chain supports many things like: - Access control - Asynchronous operations - thread local caching - resiliency (our off-process features) - buffered operations - Java Security - Authorizations - Transactions - more things... Each service does not pass through this whole APO flow on each execution, it's actually calculated and advices are unplugged dynamically in order to reduce the chain as much as possible. This information is cached per method call. Please let me know if there is more information you would like. - Ray PS: It's open source so feel free to criticise the code ( as long as it's constructive). Ray On Nov 25, 2013 8:47 AM, "Raymond Auge" <[email protected]> wrote: > Peter, you can look at http://github.com/liferay/liferay-portal for a > complete picture of how we use hibernate, with some jpa configs as well. > > Later today I can explicitly point out each case you outlined above to > clarify from our massive codebase. cache, tx, etc > > We also have plugins which participate dynamically in the same persistence > "context" if you will. > > Ray > On Nov 25, 2013 7:41 AM, "Peter Kriens" <[email protected]> wrote: > >> I am doing some research on OSGi and persistence and I find the whole >> Java persistence story quite confusing and complex. Part of my problem is >> that I see lots of frameworks but it is quite hard to see code that really >> uses those frameworks. Virtually all tutorials and examples look highly >> contrived and seem to totally ignore issues like caching, security and seem >> to be rather lax concerning transactions. >> >> I wonder if people in this forum could share with me a typical production >> source file showing: >> >> How entities are defined >> The persistent use of the entity, i.e. the part where the SQL >> will be generated. I.e. places where the PersistenceManager, EntityManager, >> SQL generation is used >> How results are cached >> >> A single source or class file per issue is best. Adding a small >> description how you use persistence (Aries, JPA, JDO, JDBC, etc), the >> primary issues you face, and describe your environment is highly >> appreciated. >> >> I know from my own experience that there is often a feeling that your own >> code is not up for showing to others but please send me the raw >> unadulterated code; I need to see how it is today, not how you think it >> should be. Obviously I am not interested in what the code does or where it >> is used so feel free to remove comments (if any!) and change names. I am >> just looking for a couple of hundred of real world samples to extract the >> patterns that are actually popular in our industry. >> >> Obviously I will not share that code with anyone and treat it fully >> confidential. Also would appreciate a little description how you use >> persistence in OSGi. >> >> So in this case, do not ask what the OSGi can do for you, but for once, >> ask what you can do for the OSGi! ;-) >> >> Please? Come on, it only takes 3 minutes. Send your 4 files to: >> [email protected] >> >> Kind regards, >> >> Peter Kriens >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "bndtools-users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/groups/opt_out. >> >
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
