Fórum

How to connect ibatis/mybatis in Liferay portlet?

enjae bicera, modificado 7 Anos atrás.

How to connect ibatis/mybatis in Liferay portlet?

New Member Postagens: 7 Data de Entrada: 23/10/15 Postagens Recentes
Hi!

I would like to ask how to connect or setup ibatis/mybatis in Liferay portlet?
Is it same with Liferay Service Builder which is Hibernate?
I tried to search but there's no reliable source that I can use for setup

Thank you emoticon

enjae
thumbnail
David H Nebinger, modificado 7 Anos atrás.

RE: How to connect ibatis/mybatis in Liferay portlet?

Liferay Legend Postagens: 14914 Data de Entrada: 02/09/06 Postagens Recentes
There's no built in support for ibatis, but many of the same issues that service builder solves you'll have to figure out how to solve yourself:

  • For 6.x, you either have a bunch of different portlets all with their own database connection pools, their own ibatis mappings, etc with no sharing or you have to manufacture a way to share one data access layer w/ all consumers.
  • If you have separate portlets w/ their own ibatis layers, you will run into issues with stale data: Portlet A and B both have an ibatis implementation to do ORM actions against table T. Portlet A and B both retrieve record R; user makes a change on Portlet A and it persists record R1; because Portlet B has no connection to Portlet A's ibatis layer, well it now has a cached copy we call record R2 which is a stale copy of the data. Problems will continue as Portlet B keeps showing R2 and Portlet A shows R1; if B tries to update R2, it will fail because ibatis will realize it is out of sync w/ the real record R1.
  • Even if you only do this for one and only one portlet, it will work in your local environ but as soon as you push it up to your production cluster, all of the issues mentioned in the previous bullet will come and bite you in the tookus.
  • In Liferay 7, you might build some sort of DS service layer to separate the ibatis dependencies from consumers, but you have to remember that much of the power of the ORM frameworks like ibatis and Hibernate is lost when you start using bridge objects to pass retrieved records around (you lose the proxies that the ORM frameworks use to track when properties or child objects change in order to persist the changes back to the DB ).
  • etc etc etc


At first it may seem like a simple problem to solve. Oh, I'll just create a portlet and add in the ORM dependencies to the portlet and build out the data access layer using the ORM and my portlet will rock! I don't need this silly ServiceBuilder thing, I can make my own...

But then one portlet becomes two portlets becomes 3 portlets becomes ... You'll face runtime issues such as running out of DB connections because you now have multiple portlets all managing their own database connection pools to feed their own ORM systems. You'll face the stale object issues because of multiple writers (either different portlets in the same node or a single portlet running on all nodes in the cluster) and, out of frustration, you'll dump 2nd level caching because you can't figure out how to coordinate all of the ORM layers to notify each other of stale records. But now your users will complain because every retrieve you do now has to come straight from the database and your performance blows chunks.

Plus, because you didn't leverage any of Liferay services, you're missing out on search/indexing capabilities, workflow capabilities, asset capabilities, LAR import/export capabilities (staging too), ...

So pretty soon they're throwing out all of the code you did, rework it the right way to fit into the portal the Liferay way, and everyone is questioning if you really knew anything about Liferay in the first place.