[01:25:50] *** struberg has quit IRC
[07:02:28] *** mbg has joined #weld-dev
[07:02:41] *** mbg has quit IRC
[07:02:41] *** mbg has joined #weld-dev
[07:29:38] *** struberg has joined #weld-dev
[08:22:36] *** struberg has quit IRC
[11:54:11] *** ge0ffrey has joined #weld-dev
[13:58:39] *** kevinpollet has joined #weld-dev
[14:25:26] *** pmuir has joined #weld-dev
[14:41:16] *** oskutka has joined #weld-dev
[14:43:39] *** oskutka has quit IRC
[15:01:29] <pmuir> kevinpollet: ping
[15:02:50] <kevinpollet> pmuir: pong
[15:03:10] <pmuir> we had an interesting idea for a demo involving caching + cdi last week
[15:03:19] <kevinpollet> yep
[15:03:25] <kevinpollet> cool
[15:03:26] <pmuir> and hoped you might be able to take a look
[15:03:32] <kevinpollet> sure
[15:03:40] <pmuir>
[15:03:46] <pmuir> basically the use case is this
[15:04:21] <pmuir> say you are using the cache to cache stuff ;-)
[15:04:34] <kevinpollet> he he
[15:04:38] <pmuir> typically something that the view layer needs, and wants very quickly
[15:04:50] <pmuir> but sometimes this data becomes invalid
[15:04:55] <pmuir> the design we suggested was this:
[15:05:11] <pmuir> use @CacheResult to cache the item
[15:05:31] <pmuir> and make the @CacheRemove method a CDI observer
[15:05:42] <pmuir> so that you can send an event and have the cache entry removed as a result
[15:05:50] <kevinpollet> yep
[15:06:08] <pmuir> this would be a nice scenario to show as it's a popular use case
[15:06:24] <pmuir> we also discussed that it might be useful to repopulate the cache at the same time
[15:06:41] <pmuir> so that the next time the client comes it doesn't need to wait while it's result is computed
[15:06:49] <pmuir> but i'm not sure how the ordering would work here
[15:08:45] <kevinpollet> the ordering?
[15:08:58] <pmuir> well CDI observer methods in CDI 1.0 aren't ordered
[15:09:13] <pmuir> so you can't guarantee to call the @CacheResult after the @CacheRemove
[15:09:27] <pmuir> which would be the neatest way
[15:09:38] <pmuir> other way would be to call the @CacheResult from the @CacheRemove
[15:09:48] <pmuir> or maybe there is a way to do this in JSR-107? Not sure
[15:09:56] <kevinpollet> I know
[15:10:03] <pmuir> with some flag on @CacheResult, I can't remember
[15:10:12] <kevinpollet> but In your explanation I see only one observer
[15:10:18] <pmuir> ok
[15:10:22] <kevinpollet> for the @CacheRemove
[15:10:51] <pmuir> ah you want to use @CacheResult(skipGet=true) I think
[15:11:05] <pmuir> to update the cache
[15:11:05] <pmuir> cool
[15:11:44] <kevinpollet> why not @CachePut
[15:12:17] <pmuir> oh even better ;-)
[15:12:27] <kevinpollet> I'm working on it today
[15:12:30] <kevinpollet> ;-)
[15:12:31] <pmuir> err
[15:12:54] <pmuir> i think @CachePut is used to put a value from the method parameters into the cache
[15:13:10] <pmuir> that isn't what I want - I want to cache the result of a method call I think?
[15:13:17] <kevinpollet> ah ok
[15:13:28] <kevinpollet> in this case @CacheResult(skipGet=true) is good
[15:13:32] <pmuir> :-)
[15:14:12] <pmuir> anyway, my use case was right - until "so that the next time the client comes it doesn't need to wait while it's result is computed"
[15:14:21] <kevinpollet> if we want to have the @CacheRemove a CDI observer
[15:14:55] <kevinpollet> I have to finish my stuff on @CacheKeyParam first ;-)
[15:15:24] <pmuir> i don't think we need @CacheRemove at all, just use @CacheResult with the skipGet
[15:15:29] <pmuir> hehe
[15:16:40] <kevinpollet> I'm a little lost :-(
[15:17:43] <kevinpollet> The idea
[15:18:08] <kevinpollet> is to cache one thing the user have to see in the UI
[15:21:29] <kevinpollet> to simulate the invalid state we use @CacheResult(skipGet=true) right?
[15:21:37] <kevinpollet> or I'm in the wrong :D
[15:30:16] <kevinpollet> @CacheResult(skipGet=true) need to be an observer
[15:32:07] <kevinpollet> pmuir: here?
[15:32:24] <pmuir> sorry here
[15:32:33] <pmuir> just mention me and then I get notifications
[15:32:37] <pmuir> yes, that is the idea
[15:33:04] <pmuir> kevinpollet: ^^^
[15:33:23] <kevinpollet> in this case I need to finish my work on  @CacheKeyParam
[15:34:26] <pmuir> ok :-)
[15:34:56] <kevinpollet> pmuir: If I resume
[15:35:31] <kevinpollet> we have one method with a long computation time
[15:35:55] <kevinpollet> this result of this method is displayed on the UI
[15:36:10] <kevinpollet> and we have one method annotated with @CacheResult
[15:36:17] <kevinpollet> which call this method
[15:36:47] <kevinpollet> subsequent calls will be read from cache
[15:37:11] <kevinpollet> and a method annotated with @CacheResult(skipGet=true) which is a CDI observer
[15:37:29] <kevinpollet> which invalidate the data in the cache a new computation is done
[15:37:32] <kevinpollet> and cached
[15:37:37] <pmuir> yes
[15:37:54] <kevinpollet> ok cool
[15:38:13] <kevinpollet> to trigger the CDI we could use the EJB timer service
[15:38:22] <kevinpollet> pmuir: WDYT?
[15:38:29] <pmuir> we should probably have two examples - one without the recompute (recompute is done when data is requested again i.e. lazy recomputation) and one with recompute (i.e. eager recomputation)
[15:38:41] <pmuir> kevinpollet: actually I would just make this related to some other action
[15:38:47] <kevinpollet> ok
[15:38:54] <pmuir> e.g. user uploads a new profile pic
[15:38:56] *** stuartdouglas_ has joined #weld-dev
[15:39:11] <pmuir> this kicks of the rebuild of the thumbnail pic
[15:39:15] <pmuir> something like that
[15:39:55] <pmuir> do you see the kind of situation i'm thinking of?
[15:40:03] <pmuir> btw it would be good to add ejb
[15:40:08] <pmuir> to make the invocation async...
[15:40:28] *** stuartdouglas has quit IRC
[15:40:28] *** stuartdouglas_ is now known as stuartdouglas
[15:41:35] <kevinpollet> I like the idea of the profile pic
[15:43:55] <pmuir> or better to use seam's async support to avoid ejbs perpahs?
[15:43:58] <pmuir> up to you
[15:45:07] <kevinpollet> pmuir: ok
[15:47:16] <kevinpollet> pmuir: I'm thinking of a thumbnail pic service
[15:47:23] <pmuir> yes, I think this is good
[15:47:27] <kevinpollet> the user upload a pic
[15:47:30] <pmuir> it's easy for everyone to understand ;-)
[15:47:43] <kevinpollet> but here the browser will cache the pic
[15:48:39] <kevinpollet> pmuir: forget my last sentence :)
[15:51:51] <kevinpollet> pmuir: sorry for my misunderstanding I'm not very awake today :)
[15:52:01] <pmuir> haha I know the feeling
[15:53:10] <kevinpollet> pmuir: I will work on it asap
[15:53:16] <kevinpollet> I just need to find some time :(
[15:53:20] <pmuir> thanks!
[15:53:26] <pmuir> sure :-)
[15:57:02] <kevinpollet> pmuir: Normally I will send to you and manik my article for the Infinispan blog tomorrow
[15:57:10] <pmuir> :-)
[15:57:12] <kevinpollet> for a first review :)
[16:17:29] *** pmuir has quit IRC
[18:03:49] *** kevinpollet_ has joined #weld-dev
[18:03:50] *** kevinpollet has quit IRC
[18:03:50] *** kevinpollet_ is now known as kevinpollet
[18:05:06] *** kevinpollet has quit IRC
[18:14:04] *** ge0ffrey has quit IRC
[19:04:03] *** struberg has joined #weld-dev
[19:24:29] *** mbg has quit IRC
[19:34:06] *** alesj has joined #weld-dev
[19:50:28] *** alesj has quit IRC
[20:22:02] *** struberg has quit IRC
[22:00:31] *** kevinpollet has joined #weld-dev
[23:32:55] *** struberg has joined #weld-dev
[23:43:50] *** kevinpollet has quit IRC
[23:52:26] *** struberg has quit IRC





top