tag:blogger.com,1999:blog-4667121987470696359.post4268647037697960598..comments2023-07-28T02:46:58.321-06:00Comments on Sleepless in Salt Lake City: An Example of Caching with REST using Jersey JAX-RSSanjay Acharyahttp://www.blogger.com/profile/01933976956977901677noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-4667121987470696359.post-15213281678234727462013-10-22T12:13:34.685-06:002013-10-22T12:13:34.685-06:00Nice article. But will it work on clustered enviro...Nice article. But will it work on clustered environment? Not sure how the Etag will work in cluster. Do you have any thought on this?<br />Thanks & Regards<br />KannanAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-4667121987470696359.post-66695236461699347022009-03-31T04:07:00.000-06:002009-03-31T04:07:00.000-06:00...Exactly.Actually i'm using @version to annotate......Exactly.<BR/>Actually i'm using @version to annotate a Long property on my domain objects. In Rest services i use an helper method that build Etag from entity id and version in this way:<BR/><BR/><I><BR/>/**<BR/> * Create a EntityTag based on entity version and request Accept header. The media type parameter is here to<BR/> * avoid mediatype mismatch between the request and the cached value.<BR/> * <BR/> * @param mediaType<BR/> * @param dto<BR/> * @return Entitytag<BR/> */<BR/> private static <D extends BaseDTO> EntityTag createEtag(MediaType mediaType, JAXBConverter<D> converter) {<BR/> StringBuilder sb = new StringBuilder(converter.getDTOs().size() * 40);<BR/> for (BaseDTO dto : converter.getDTOs()) {<BR/> sb.append(dto.getVersion()).append(";")<BR/>.append(dto.getId());<BR/> // remove version from dto<BR/> dto.setVersion(null);<BR/> }<BR/> EntityTag result = new EntityTag(sha1(String.format("%s;%s", sb.toString(), mediaType.toString())));<BR/> return result;<BR/> }<BR/><BR/></I><BR/>where sha1 is a method to compute a message digest and JAXBConverter<D> is an interface for a generic DTO wrapper that handle URI resource resolution and JAXB based xml/json marshalling/unmarshalling.Anonymoushttps://www.blogger.com/profile/15798126923814884997noreply@blogger.comtag:blogger.com,1999:blog-4667121987470696359.post-28628432091199122442009-03-11T22:36:00.000-06:002009-03-11T22:36:00.000-06:00It would be interesting to know how you would mana...It would be interesting to know how you would manage the optimistic locking using @version with cache expirations. One could use time stamp or just a version number when using optimistic locking. Looking forward to your findings...Sanjay Acharyahttps://www.blogger.com/profile/01933976956977901677noreply@blogger.comtag:blogger.com,1999:blog-4667121987470696359.post-39839230756977814722009-03-07T17:16:00.000-07:002009-03-07T17:16:00.000-07:00Nice post, as others you made on the same argument...Nice post, as others you made on the same argument. I've heard about cache capability as one of the plus of rest service so I was looking for an example of rest caching but hadn't not found anything, till now. I found it very instructive. I would like to investigate more on possible interactions between etag and @version jpa annotation for optimistic locking. Actually look like that using a timestamp with @version could provide a viable solution for cache management too. But what happens when the field used with @version is a long or a integer that is incremented at each revision by the entity manager? ETAG can be used with incremental version info?<BR/>Regards<BR/>domenicoAnonymoushttps://www.blogger.com/profile/15798126923814884997noreply@blogger.com