I agree with the idea. If we had web services to allow data updates I
think it would be very beneficial primarily because it means we'd
significantly enhance and open up uPortal's API to allow for more
innovation from external applications.
However I'm wondering if it would not quite solve the issue you found.
Recently as part of the entity-based PAGS group entity import process I
verified that the ant data-import command invalidates caches on the
target cluster. I believe the node running the ant command effectively
joins the cluster for a short period of time (it writes it's address and
connection information into the same jgroups-queried table that all
other nodes in the cluster communicate with -- uPortal uses access to
the same DB to identify cluster members). I did verify in my testing
that doing an ant data-import and then logging in on a cluster node did
invalidate the caches and behave nicely.
I think the same situation would apply in the use case you mentioned.
Whether the application executing the ant data-import or another node in
the cluster performs the data update, it should invalidate the
corresponding cache entries on the other nodes in the cluster. Since
you got an optimistic lock exception it suggests to me that either the
cache invalidation wasn't working (perhaps the machine that ran the ant
data-import command had firewall restrictions to prevent it from talking
to the other nodes in the cluster), or that we have an error in the
cache invalidation configuration.
If it is the former situation, then you are right that having a node in
the cluster do the actual update would be more transparent. If it is
the latter, I'd expect that doing the same process you mentioned with a
web service invocation to node 1 and a later admin UI connection to node
2 would exhibit the same behavior.
James Wennmacher - Unicon
480.558.2420
On 12/09/2014 10:36 AM, Andrew Petro wrote:
I ran into some hassle this morning attempting to apply a hotfix
configuration change through the Portlet Manager UI to a portlet
publication that had just been updated by an entities import job.
Use case was that for silly reasons the entity data in source control
was wrong in a known way and I needed to tweak a
group-subscribe-permission-on-portlet-grant after the import job ran
to import a portlet definition that granted SUBSCRIBE to the wrong group.
Since the current import process runs directly against the database
(as mediated by a local uPortal ApplicationContext, a local JPA entity
manager, etc.), rather than through the live portal application
context / JPA entity manager, etc., apparently it can put the portal
into a state where the objects in the running portal will fail
Hibernate optimistic locking checks when you try to save changes to
them. This is annoying, and probably could be lessened through more
careful error handling, and anyway it apparently goes away after
sufficient cache timeouts or something. No doubt tactical gains could
be made in looking into that more deeply and tweaking.
But this also yields some strategic thoughts: it seems to me that
import would be better off actuating web services against the "real"
uPortal application context / entity manager / etc., rather than
spinning up a separate local ApplicationContext for this purpose --
and that moving to such a model might help make viable simplifying the
uPortal build tooling, since the task of import tooling would become a
tighter matter of invoking the right web services with the right data
and credentials rather than spinning up local services, connections to
the database, etc.
That thought backlogged as
https://issues.jasig.org/browse/UP-4336
Andrew
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
