[10:51:38 CDT(-0500)] <EricDalquist> that's a fun bug in calendar portlet 1.0
[10:52:30 CDT(-0500)] <athena> i guess? i'm actually surprised that that causes such misbehavior
[10:52:47 CDT(-0500)] <EricDalquist> so in uP4 I added entity versioning to all our JPA objects
[10:52:53 CDT(-0500)] <EricDalquist> as a form of optomistic locking
[10:53:03 CDT(-0500)] <EricDalquist> every time an object is updated its version number increments
[10:53:07 CDT(-0500)] <athena> ah
[10:53:08 CDT(-0500)] <EricDalquist> and the updates all include the version number
[10:53:18 CDT(-0500)] <athena> so the misbehavior is up4-specfic?
[10:53:22 CDT(-0500)] <EricDalquist> prevents concurrent updates from stepping on each other
[10:53:23 CDT(-0500)] <EricDalquist> yeah
[10:53:33 CDT(-0500)] <EricDalquist> essentially concurrently updating portlet preferences has always been bad
[10:53:33 CDT(-0500)] <athena> well, good to know
[10:53:46 CDT(-0500)] <EricDalquist> in uP3 it would fail silently, last update always won
[10:53:53 CDT(-0500)] <EricDalquist> in uP4 it fails loudly
[10:54:06 CDT(-0500)] <EricDalquist> if you really have a concurrent preference update use case you need to sync on the session or some such
[10:54:36 CDT(-0500)] <athena> i know we actually talked at this at some point
[10:54:50 CDT(-0500)] <athena> and for that portlet we knew it was fine if the last update won
[10:55:02 CDT(-0500)] <athena> don't think there was discussion around it actually creating performance problems
[10:55:02 CDT(-0500)] <EricDalquist> huh
[10:55:05 CDT(-0500)] <EricDalquist> yeah
[10:55:34 CDT(-0500)] <EricDalquist> well and I'm going to look into adding more logic in the preferences service
[10:55:41 CDT(-0500)] <EricDalquist> so that if you don't actually change anything
[10:55:45 CDT(-0500)] <EricDalquist> and call store nothing happens
[10:55:45 CDT(-0500)] <athena> ok, great
[10:55:56 CDT(-0500)] <EricDalquist> since that code looks like it will be setting the same value every time
[10:56:08 CDT(-0500)] <athena> well, the days is
[10:56:25 CDT(-0500)] <athena> i worry that other portlets may be doing similar things, and not always setting the same value
[10:56:33 CDT(-0500)] <EricDalquist> yeah
[10:56:37 CDT(-0500)] <athena> like the news reader portlet definitely used to set the feedId as a preference
[10:56:48 CDT(-0500)] <EricDalquist> on every ajax request?
[10:56:50 CDT(-0500)] <athena> so that when you came back to the portlet it would remember the last feed you looked at
[10:56:57 CDT(-0500)] <athena> yes
[10:56:59 CDT(-0500)] <EricDalquist> so it all depends
[10:57:12 CDT(-0500)] <EricDalquist> it seems like the cal portlet does lots of concurrent ajax requests per user
[10:57:23 CDT(-0500)] <EricDalquist> in that case modifying prefs in each can be bad
[10:57:46 CDT(-0500)] <athena> i don't think it should be doing concurrent ajax requests
[10:58:00 CDT(-0500)] <EricDalquist> I'm not sure how else bruce could be getting that error
[10:58:01 CDT(-0500)] <athena> i'm not sure why we'd be seeing those at all, actually
[10:58:13 CDT(-0500)] <athena> the portlet makes one when loaded
[10:58:24 CDT(-0500)] <athena> then makes a request any time the user changes the date, etc.
[10:58:32 CDT(-0500)] <EricDalquist> hrm
[10:58:44 CDT(-0500)] <EricDalquist> so I just realized there is locking in the prefs service too
[10:58:58 CDT(-0500)] <athena> you know . . . i think they have a single-feed version of the calendar and may be displaying a bunch of calendar portlets on a page
[10:59:00 CDT(-0500)] <EricDalquist> in prefs service .store the code gets a Lock scoped to the portlet entity
[10:59:02 CDT(-0500)] <athena> don't know if that might be a factor
[11:00:21 CDT(-0500)] <EricDalquist> oh ... huh
[11:00:29 CDT(-0500)] <EricDalquist> my lock and tx are not scoped correctly