[TRUEVFS-12] When mounting an archive file, don't cache its entry if it's STORED within a ZIP file. Created: 09/May/11  Updated: 27/Feb/16

Status: Open
Project: TrueVFS
Component/s: TrueVFS Kernel Implementation, TrueVFS Kernel Specification
Affects Version/s: TrueVFS 0.9
Fix Version/s: backlog

Type: Improvement Priority: Minor
Reporter: Christian Schlichtherle Assignee: Christian Schlichtherle
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to TRUEZIP-109 Provide InputSocket.newSeekableByteCh... Closed
is related to TRUEZIP-6 Do NOT compress an already compressed... Closed
Tags: CACHE, STORED, ZIP

 Description   

When mounting the virtual file system of an archive file which is located within another archive file, the Kernel currently extracts the entry representing the inner archive file from the outer archive file into a cache entry (flagged by FsInputOption.CACHE) first before opening the cache entry for reading. This allows the outer archive file to get updated with new content independently from the inner archive file.

However, extracting the inner archive file adds to the run time when mounting its virtual file system which can be painful is the inner archive file is very large. This could be avoided if...

(1) the outer archive file is a ZIP file and the inner archive file has been STORED rather than DEFLATED to it, and if....
(2) it could be figured that updating the outer archive file independently from the inner archive file is not required by the application.

This would require the following:

(a) The class RawZipFile would need to provide a method (approximately named getReadOnlyFile(ZipEntry)) which returns a ReadOnlyFile which allows to read the entry directly.
(b) The method ZipInputShop.getInputSocket would need to use this method for any STORED entry.
(c) In the event of (2), either the method FsDefaultArchiveController.mount should not issue the FsInputOption.CACHE flag to its parent file system or the class FsCachingController.getInputSocket should ignore it.

My assumption: This is a comparably big coding effort for its minor performance benefit - it really only helps when mounting large inner archive files from outer ZIP files.



 Comments   
Comment by Christian Schlichtherle [ 23/May/11 ]

A part of the requirements has been addressed by TrueZIP 7.1, namely the API changes to the archive file driver required for (c) - see FsArchiveDriver.get(In|Out)putSocket

Comment by Christian Schlichtherle [ 06/Jun/11 ]

If the ZipFile class could provide a SeekableByteChannel for STORED entries, then the FsCachingController might not need to create a cache entry for it.





[PDF_RENDERER-151] The Softreference based cache in PDFFile class causes "outages" because of high garbage collector activity Created: 13/Jun/12  Updated: 13/Jun/12

Status: Open
Project: pdf-renderer
Component/s: None
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: liptga Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 4 hours
Time Spent: Not Specified
Original Estimate: 4 hours
Environment:

java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)

Windows 7 Enterprise X64


Attachments: Zip Archive PDFRendererGCTest.zip     Zip Archive testresults.zip    
Tags: cache, garbage-collector

 Description   

We experienced "outages", periods without any JVM activity (i mean any response to clients) in our system. We realized, that this is caused by the soft reference cache in PDFFile class.

I created a small test project (eclipse project), which contains the followings:

  • a hacky subclass of PDFFile and Cache classes, which lets you basicly switch off this built in caching
  • a unit test containing one test method with caching and without caching to let you to compare the results. A PDF file is converted into a set of JPG files. ~300 pages.

I also traced the JVM, and I attached the results. 256M and 512M heap with and without caching. From the graphs it can be easily seen, that the caching in general takes a lot of CPU time for the garbage collection, and there are "outages", when the whole CPU time is consumed by GC. On the other hand without caching the whole process is not slower at all, and the GC activity and heap size is pretty normal.

I would suggest to throw away this caching, or to make it switchable.



 Comments   
Comment by liptga [ 13/Jun/12 ]

Hmm. It would be nice to have a fix for it. I get an exception during startup (i have no idea, why is it not coming with JUnit test in eclipse), that my class is has no matching signature (my subclass). See http://stackoverflow.com/questions/2877262/java-securityexception-signer-information-does-not-match

So right now I am enforced to include a pdfrenderer.jar without signature information in the META-INF folder, wich solution I really dont like.





[OPENPTK-329] READ cache for Subject Created: 14/Mar/12  Updated: 14/Mar/12

Status: Open
Project: openptk
Component/s: Server
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: Scott Fehrman Assignee: Scott Fehrman
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: cache, server, session

 Description   

Implement a cache for Subject data that is returned from a READ Operation. The cache would be added to the user's Session:

Factors to consider when to use the cache:

  • age of the subject ... number of seconds, (default = 10)
  • operation performed on the subject, clear cache if UPDATE / DELETE
  • max number of Subjects (Cache size)
  • the cache mechanism should be configurable including a mechanism to disable it

This would provide performance improvements when a Subject is READ more than once, over a short period-of-time.






[MQ-353] CacheSweeper Thread can never exit from run Created: 15/Apr/14  Updated: 22/Jul/14

Status: Open
Project: mq
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: thembones410 Assignee: Ed Bratt
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Tomcat 7.0.42
OpenMQ 5.0


Tags: cache, sweeper, ums, umsservlet

 Description   

Not 100 percent sure I'm at the correct place for this report and who is writing on the UMSServlet stuff. If this is the wrong place, please guide me in the right direction.

I'm using the open-mq5.0 library from https://mq.java.net/, other versions might be affected too.

This especially striked me when manually starting a UMSServlet connected to an embedded broker on Tomcat and trying to cleanly destroy() it:

com.sun.messaging.ums.service.CacheSweeper can never exit correctly due to assignment which will always be true in line 169 in run() method:

com.sun.messaging.ums.service.CacheSweeper.java
 public void run() {
   while (isRunning = true) {
      // do some work....
   }
 }
}

A not so important thing that occurred to me when looking at the class: there's a typo in the thread's name (line 68), don't think it's worth to open an own bug for this. "CacheSweper" probably should be "CacheSweeper".

com.sun.messaging.ums.service.CacheSweeper.java
 private static final String myName = "CacheSweper";

Thanks,






[JPA_SPEC-32] Add a property to define cache implementation in persistence.xml Created: 27/May/12  Updated: 05/Apr/13

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: c.beikov Assignee: ldemichiel
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: cache, configuration, jpa, persistence

 Description   

The cache implementation for the second level cache currently has to be configured via vendor specific properties but the semantics of the Cache are already reflected in the interface javax.persistence.Cache. The cache implementation should be configurable via persistence.xml.

I propose the property javax.persistence.cache.provider and the value of it should be the class name of the cache provider that actually implements javax.persistence.CacheProvider.

The CacheProvider interface could look similar to the RegionFactory interface hibernate actually uses.
Including the option to specify cache implementations in a stadardized way will improve the portability of applications and also make people to use the standard JPA provider of a container instead of packaging their own one in their applications.



 Comments   
Comment by arjan tijms [ 08/Nov/12 ]

Maybe it's also convenient to take JCache into account, instead of or perhaps next to a new javax.persistence.CacheProvider? Just like JPA 2.1, JCache is slated for inclusion into Java EE 7.

Comment by c.beikov [ 09/Nov/12 ]

I wasn't aware of the status of JCache back when I made this issue. Integrating JCache is IMHO the right way!





[JAX_RS_SPEC-39] Client Cache Support Created: 19/Feb/11  Updated: 18/Nov/15

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.0
Fix Version/s: ice box

Type: New Feature Priority: Major
Reporter: mkarg Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: cache, client_api

 Description   

A major benefit of HTTP is the possibility of transparent caching. Such caches not only make sense as separate proxy caches and caches on the server, but have proven useful especially built into the client applications (best example is the typical web browser which speeds up loading by reusing fresh objects found within its local cache).

When providing a specification for a Client API for JAX-RS, it makes very much sense to support local caching.

(a) Automatic use of local caches

Java SE since long time comes with support for local caches, but actually did never supply an implementation for one, so least people know about this feature. So without automatic use of local cache by the Client API implementation itself, the typical Client API consumer will build the cache into his application. But such a cache shouldn't be part of the application, as there is just no difference between that cache and any other cache for any other Client API based applilcation.

So it makes pretty sense that the Client API provides features to enable or disable local caching and then make use of local caches itself, without further caches coded into the surrounding application.

As a client's source code shall not be dependent of any particular implementation of the Client API, the API for configuring the cache must be part of the JAX-RS specification.

(b) Answering conditional requests using local caches

The Client API is expected to support conditional requests. It makes sense that before sending the request the local cache is checked whether it contains a fresh object fulfilling the request (e. g. when having asked for a resource before and now asking for a fragment of it, or when polling frequently for the same resource but the resource was configured by the server to stay fresh for rather long time).

As a client programmer likes to guarantee how his application works (i. e. whether it does local caching or not), it must be clearly specified by the JAX-RS specification, that an implementation must resolve conditional requests first using local caches, as soon as local caches are enabled by the client program using the JAX-RS Client API.



 Comments   
Comment by Marek Potociar [ 10/May/11 ]

Downgraded and retargeted based on the outcome of the EG discussion:
http://java.net/projects/jax-rs-spec/lists/jsr339-experts/archive/2011-05/thread/1#00006

Comment by Marek Potociar [ 07/Dec/11 ]

Un-assigning for now.

Comment by puce [ 18/Nov/15 ]

Any update on this feature request?





[GRIZZLY-1216] [StaticHttpHandler] Wrong Content-length on cached changed files Created: 09/Mar/12  Updated: 12/Mar/12  Resolved: 12/Mar/12

Status: Closed
Project: grizzly
Component/s: http
Affects Version/s: 2.1.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: davide_137 Assignee: Ryan Lubke
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: cache, filecache, server, static

 Description   

Hello,
I think I discovered a bug on serving changed and cached files. I tried with .css and .less ones.

  • The first time is asked a content, everything is ok
  • The second time, file is served from cache and everything is still ok
  • After file changes, served file is changed, but his content length is the same as the first cached version

This causes trunk files or extra chars at the request end, depending of length diffs.

Before to test, I patched content-type issue, as described here: http://java.net/jira/browse/GRIZZLY-1014

Best Regards,
Davide



 Comments   
Comment by Ryan Lubke [ 09/Mar/12 ]

I don't believe this qualifies as a bug.

By default, once an entry is cached, the cache entry will never be invalidated nor updated. For testing purposes, you can call FileCache.setSecondsMaxAge() with some value in seconds. So say for development, you could set the value to 30. Make an initial request - expected content; update the content; make a second request - same content as the first (maybe garbage depending on if the size of the file was increased or decreased). Wait at least 30 seconds and request the content - the changes should be apparent.

For production, if you need to be able to tweak the static content, you could set the value to be higher and plan for some lag time on when the update occurs.

Comment by davide_137 [ 10/Mar/12 ]

Thank's a lot for your reply, I will use this approach as workaround, but I think I told you this issue in a wrong way

When you modify a file, you can see the changes on the response, except for the content length.
This will cause trunked file response or response with extra characters at the end of file.

To test it I created a StaticHttpHandlerPatch class wich extends StaticHttpHandler and overridden handle method, to patch http://java.net/jira/browse/GRIZZLY-1014 bug.

I tried with test.less file:

@color: #ff0000;
body

{ background-color: @color; }

Responses are OK, until file not change, but after changing file as follow, adding a for example a new line:

/* FOO BAR */
@color: #ff0000;
body

{ background-color: @color; }

Response is trunked as follow, because file is changed, but content length is the same as the first version:
/* FOO BAR */
@color: #ff0000;
body {
background-co

I don't thing is a wanted behavior.

I tried to solved it on my self But I don't understand grizzly so good to understand how to debug FileCache Filter.

Talking with you I noticed the really strange thing that after first time, control never pass again into handle method, but served file is the new version.

Hope to be useful, Davide.

Comment by Ryan Lubke [ 10/Mar/12 ]

First thing to keep in mind, is when an entry is cached, the ByteBuffer resulting from mapping (either using a standard ByteBuffer or a MappedByteBuffer - depending on FileCache configuration) the file is cached. This buffer's limit/capacity will not change until the cache entry is invalidated.

That said, I believe whether or not you see changes immediately will depend on a couple of factors (assuming a MappedByteBuffer as the behavior you describe certainly implies it).

1) Are you modifying the cached MappedByteBuffer directly?
2) Are you modifying the file (say vi or some editor and saving the changes)?

Ignoring option one - as in all likelihood that isn't the case.

For case two, when a MappedByteBuffer is used, this will be highly dependent on the OS.

In your case, it seems the buffer will be updated with the new content, however, the buffer's size remains the same hence the truncation and unchanged content length.

Regarding the fact that control doesn't go into the handle method after the initial request, that's due to the FileCache serving the content. If there's a cached entry, there is no need for control to go that far.

Comment by Ryan Lubke [ 11/Mar/12 ]

Additionally file caching can be disabled completely - which may be a better option for development purposes.

Comment by davide_137 [ 11/Mar/12 ]

Ok, I understand how it works.

1) Are you modifying the cached MappedByteBuffer directly?

No

2) Are you modifying the file (say vi or some editor and saving the changes)?
For case two, when a MappedByteBuffer is used, this will be highly dependent on the OS.

Designers changes files regularly, using sublime text or textmate editors on MAC OS X 10.6+ or Linux

In your case, it seems the buffer will be updated with the new content, however, the buffer's size remains the
same hence the truncation and unchanged content length.

I think you're right.

Development does not worry me, until I can disable cache by setting FileCache.setSecondsMaxAge(0), but files can be changed even in production environments and I expect that an http server reads files changes or not.
I don't think is a good idea to serve broken files.

Comment by Ryan Lubke [ 12/Mar/12 ]

Actually, a better way to disable the file cache would be:

HttpServer server = HttpServer.createSimpleServer();
for (NetworkListener l : server.getListeners()) {
   l.getFileCache().setEnabled(false);
}

Will look into some changes to periodically stat the file and dump the cache entry if the file has changed.

Comment by oleksiys [ 12/Mar/12 ]

Not sure if it makes sense or not, just my 2 cents.
IMO it might be a good idea to split files into 2 subfolders:
1) dynamic
2) static

disable cache for "dynamic" subfolder and keep it enabled for "static".

But here we come to problem that Grizzly doesn't support filecache enabling/disabling per StaticHttpHandler, you can either enable or disable it per NetworkListener.
So it's something we have to implement (will appreciate if you can file issue for us).

Thanks.

Comment by davide_137 [ 12/Mar/12 ]

Tank's a lot for your reply!
I'm using grizzly to develop a suite distributable to our designers, because I like Grizzly and the possibility of remove Application Server dependencies.

To do that I think I will need to know Grizzly in deep and develop on it where i find something to implement..

If you want I can discuss and share with you my job, while I'm doing it.

Thanks, Davide.

Comment by oleksiys [ 12/Mar/12 ]

Well, ideally you shouldn't know Grizzly that deep )
Let us know if you think something is missed, will appreciate feedback and/or contributions.

Thanks.

Comment by oleksiys [ 12/Mar/12 ]

FYI
http://java.net/jira/browse/GRIZZLY-1219

Comment by Ryan Lubke [ 12/Mar/12 ]

After a somewhat lengthy offline discussion on this issue, for now, we're going to update the documentation to state that if there are plans to modify files at runtime, then FileCache shouldn't be used.

Comment by davide_137 [ 12/Mar/12 ]

Ok, thank's a lot





[GLASSFISH-20672] Deploying new version of ear with components with new version numbers caches javaws to break due to caching in java 7 update 21 Created: 28/Jun/13  Updated: 28/Jun/13

Status: Open
Project: glassfish
Component/s: None
Affects Version/s: 3.1.2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: gcruscoe Assignee: michael.y.chen
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Java 7u21


Tags: app-client, appclient, cache, java, java7, java_7, java_web_start

 Description   

When we switched to Java 7 update 21 from Java 7 update 17 we noticed that the apps that we run with Java Web Start started to fail to start after a new deployment of the same app with a different version number.

It seems the auto-generated jnlp files are referencing a full path to the component (including the version) and when it gets a 404 (because the file can now be found under the very similar url with just the build number different).

It seems this could be a bug with Java 7 update 21 or an issue with what files are being cached because of the Java Web Start on glassfish 3.1.2.2.

I could not find any bug for Java or glassfish for this.

Example Deploy
Eample-ear-1.0.1
which contains the client app
Example-app-1.0.1

Run the JavaWS app
javaws https://ourserver.ourdomain:8181/ExampleApp
Success!

Then make a new build and deploy
Example-ear-1.0.2
which includes
Example-app-1.0.2

And run
javaws https://ourserver.ourdomain:8181/ExampleApp

And we get a file not found for something like:

https://ourserver.ourdomain:8181/___JWSappclient/xxxx/xxxxx/xxxxx/Example-app-1.0.1/xxxx/xxxxx

Please let me know if you need any more information.






[GLASSFISH-17377] enabling web cache hangs server Created: 01/Oct/11  Updated: 18/Oct/11  Resolved: 18/Oct/11

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1.1
Fix Version/s: 3.1.2_b06

Type: Bug Priority: Major
Reporter: rkolar02 Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File jstack.txt     HTML File livedump    
Tags: cache

 Description   

This deployement descriptor hangs server. After removing, glassfish works fine

  • <cache enabled="true" timeout-in-seconds="300">
  • <cache-mapping>
  • <url-pattern>*.gif</url-pattern>
  • </cache-mapping>
  • <cache-mapping>
  • <url-pattern>/favicon.ico</url-pattern>
  • </cache-mapping>
  • <cache-mapping>
  • <url-pattern>/robots.txt</url-pattern>
  • </cache-mapping>
  • <cache-mapping>
  • <url-pattern>*.gif</url-pattern>
  • </cache-mapping>
  • <cache-mapping>
  • <url-pattern>*.html</url-pattern>
  • </cache-mapping>
  • </cache>

attaching thread stack dump from locked system.



 Comments   
Comment by Shing Wai Chan [ 09/Oct/11 ]

Can you attach a simple test case to illustrate this?
From the log, it seems the mod_jk is used. Can you provide more details on your env?

Comment by rkolar02 [ 10/Oct/11 ]

Its Apache with ajp_proxy connected to Glassfish. Application will hang after cache timeout. (it works fine for first 300 seconds, then hangs during check for changed files).

Comment by Shing Wai Chan [ 10/Oct/11 ]

Can you provide a simple test war and the url requests that you have used?

Comment by Shing Wai Chan [ 12/Oct/11 ]

There was a cache hang issue, http://java.net/jira/browse/GLASSFISH-12891
and has been fixed in 3.1.

I have a simple war file with the above xml configuration. It is working fine.
Please provide more information and a test war file so that we can debug further.

Comment by Shing Wai Chan [ 12/Oct/11 ]

Is the same app without ajp_proxy?

Comment by rkolar02 [ 13/Oct/11 ]

i cant make application war available to public

Comment by rkolar02 [ 13/Oct/11 ]

Did you tried during your war testing to load gif file to make sure its get cached? Because it seems that glassfish hangs on cache refresh and *.gif is TWICE in cache conf. We have /something.gif located in root server directory and its loaded often.

Comment by rkolar02 [ 13/Oct/11 ]

It is the same withoyt ajp_proxy. Yes. I can reporoduce it at any time.

Comment by rkolar02 [ 13/Oct/11 ]

stack dump from hanged machine without AJP

Comment by Shing Wai Chan [ 14/Oct/11 ]

Can you attach a war file to reproduce the issue?

Comment by Shing Wai Chan [ 14/Oct/11 ]

I see the issue now. The issue is triggered by duplicate entry for *.gif and then accessing a gif file.
As a workaround, one can remove the extra *.gif entry in deployment descriptor.

Need more investigation on the fix.

Comment by Shing Wai Chan [ 18/Oct/11 ]

fix in 3.1.2:
Sending web-glue/src/main/java/com/sun/appserv/web/cache/filter/CachingFilter.java
Transmitting file data .
Committed revision 50320.

fix in trunk:
Sending web-glue/src/main/java/com/sun/appserv/web/cache/filter/CachingFilter.java
Transmitting file data .
Committed revision 50321.





[EJB_SPEC-100] Provide @Idempotent functionallity to the EJB Container Created: 18/Mar/13  Updated: 05/Apr/13

Status: Open
Project: ejb-spec
Component/s: None
Affects Version/s: 3.2
Fix Version/s: Future version

Type: Improvement Priority: Major
Reporter: rherschke Assignee: marina vatkina
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: cache, container, ejb, idempotent, interceptor

 Description   

My proposal is to add functionality in the EJB-Container to support @Idempotent for Stateless EJB methods.

A method is idempotent, when a call to this method does not have any side-effects. This means, that multiple calls to such a method always give the same result.

So a container could provide this functionality for methods of a Stateless Session Bean, marked with @Idempotent to cache the result of the method for further calls.

An example:

@Stateless
public class MyService {

    @Idempotent
    public Long add(Long a1, Long a2) {
        return a1 + a2;
    }
}

With this, a container is told to handle each call with the same arguments idempotent and return exactly the same value. So a call:

@Stateless
public class AnotherService {

    @EJB
    MyService myService;

    public void someMethod() {
        // assuming, this is the first call ever to this service's method...
        // the container calls the method directly and caches the result.
        System.out.println(myService.add(1024, 42));

        // the container will return always the same value, read from a cache, without explicitly call the method.
        for(int i = 0; i<10; i++) {
            System.out.println(myService.add(1024, 42));
        }
    }
}

A container is responsible for caching the result of the method as well as how long or under which circumstances the result is cached (e.g. WeakReference).

Another responsibility for the container is the error handling and transaction rollback for idempotent methods, especially in cluster environments. (see the similar functionality with weblogic.javaee.Idempotent, but my proposal goes a bit further).

This would be a performance gain, but also a potential risk for developers, that do not know, what they exactly do.

I think, there is a general need for this functionality, even in REST-Resources or in Cluster-Environment to simplify things and to standardize the behavior of containers in this way.

Comments are requested



 Comments   
Comment by arjan tijms [ 19/Mar/13 ]

I like the proposal, but want to add that the JCache annotations with respect to the caching aspect do something similar. See e.g. javax.cache: The new Java Caching Standard

Most JCache annotation examples work with the concept of a getter and setter method though (I don't know if @CacheResult and @CachePut can be applied to the same method), but it would probably be useful to coordinate with JCache for this aspect.

Comment by rherschke [ 19/Mar/13 ]

Hi Arjan,

yes, I appreciate to see JSR-107 in next Java EE spec.

Although you could build an @Idempotent method with javax.cache Annotations (or (I already do this) by an proprietary interceptor), there is one little exception:

If the container should handle the "tracking of idempotent method results", he could even decide if - or if not - it has to construct the bean instance itself.

Look at the second example above. The container already injects just a proxy at @EJB MyService myService. The bean at this state in some container implementations isn't instantiated itself nor is it caught from the bean instance pool. The method myService.add() is proxied with the logic to decide whether to return the cached value or to get an instance from the pool (or instantiate one) and invoke the method.

The javax.cache Annotations acts like an interceptor with an "AroundInvoke" method, that does the caching logic. But to have the interceptor's "AroundInvoke" executed, the bean (which is returned from InvocationContext#getTarget()) is completely instantiated before the execution. This isn't necessary in the case, the container is responsible.

Next, the @Idempotent handling by the container is not only responsible for caching the result but also for doing a retry of a method in a cluster environment on another cluster-node instance for example in case the current cluster-node result in an error (which is not an @ApplicationException). This is true, because of the convention behind @Idempotent which means, ALL invocations of this method - even on another cluster-node instance WILL return the SAME value under the same invocation conditions (parameter values...).

So JCache is really fine, but I compare it a bit with @Asynchronous, that is completely the responsibility of the container too.

Many thanks for your comment and for your vote





Generated at Mon Jul 25 17:57:42 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.