Impressive ... this is the kind of stuff I was looking for. Thanks. Kind
regards,
Peter Kriens
On 27 nov. 2013, at 19:54, Raymond Auge <[email protected]> wrote:
> 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
