June 2007 - jboss-dev-forums - Jboss List Archives

[Design of JBossCache] - Re: Gravitation and POJO Cache

by jason.greene＠jboss.com

Well it looks like the option won't be necessary. Due to implementation details find will try and load an FQN as an internal id if it is not a reference. Since I am forcing internal id gets to use gravitation this will trigger the interceptor. So since it is already triggered, I also force reference lookups to gravitate as well. However, POJO operations (including reads) will NOT force gravitation. So applications must still ensure that a pojo is not gravitated after a call to find(). -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057055#4057055 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057055

18 years, 9 months

1
0
0 / 0

[Design of JBossCache] - Re: Gravitation and POJO Cache

by jason.greene＠jboss.com

The solution that Brian and I have agreed on is that I add an overloaded find method with EnumSet. It will support one option atm, FORCE_GRAVITATE and will only affect the find call. Internal references will always force gravitation on resolution. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057000#4057000 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057000

18 years, 9 months

1
0
0 / 0

[Design of JBossCache] - Re: Gravitation and POJO Cache

by jason.greene＠jboss.com

"bstansberry(a)jboss.com" wrote : | I wonder though if the overhead of managing all this exceeds that created by just always setting the option internal before resolving the reference. | I could definitely do this for resolution of internal references, you would still have to do a get on the root of your subtree with force gravitation first (as you are doing now). -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4056982#4056982 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4056982

18 years, 9 months

1
0
0 / 0

[Design of JBossCache] - Re: Gravitation and POJO Cache

by jason.greene＠jboss.com

I had been considering moving __JBossInternal__ to be an adjacent node to the initial referring node. For example attach("a/b/c/User", user); would result in: /a /b /c /User /__JBossInternal__ The problem is, of course, that multiply referenced nodes could cross, so in your case shared references between sessions would be a problem. -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4056980#4056980 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4056980

18 years, 9 months

1
0
0 / 0

[Design of JBossCache] - Re: Gravitation and POJO Cache

by bstansberry＠jboss.com

FYI, here are a couple of the main relevant threads I found from last year: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=85462 http://www.jboss.com/index.html?module=bb&op=viewtopic&t=83772 The first one has a discussion at the end re: the proper scope of ref sharing with a POJO attribute in a web session. Basically, pojos for a webapp are stored at /JESSION/hostname/contextpath/_JBossInternal_. So refs can be shared across sessions. With BR, sharing across sessions is not a good idea, as different cluster nodes can own the sessions, and thus fight over ownership of the shared pojo. But, we don't enforce that restriction. One possibility is to enforce that restriction by storing pojos at /JESSION/hostname/contextpath/sessionId/_JBossInternal_. If we did that, my initial plain cache get of /JESSION/hostname/contextpath/sessionId/ will cause gravitation of everything, and the problem goes away. (I realize the above is very FIELD-repl use case oriented; not generic. I'm mostly just thinking out loud and doing a bit of a data dump here.) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4056970#4056970 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4056970

18 years, 9 months

1
0
0 / 0

[Design of JBossCache] - Re: Gravitation and POJO Cache

by bstansberry＠jboss.com

My memory wasn't faulty. The test that limits gravitation only to reads was added in 1.4.1.SP3, rev 1.16.2.4, on 2007/03/16. Commit comment doesn't really describe the issue that led to the change. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4056966#4056966 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4056966

18 years, 9 months

1
0
0 / 0

[Design of EJB 3.0] - Re: JBossEjbParsingDeployer can't handle EJB3 jboss.xml

by adrian＠jboss.org

I have some code from last year that replaces both the EJB2 and EJB3 metadata. Haven't had time to finish it yet. But it basically replaces the EJB2 metadata with a facade over the EJB3 data (extending the EJB3 metadata to include all EJB2 features). It was originally based on the EJB3 metadata from about October but that had a number of problems so it is nowhere near exact. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4056927#4056927 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4056927

18 years, 9 months

1
0
0 / 0

[Design of JBossCache] - Re: Gravitation and POJO Cache

by bstansberry＠jboss.com

For FIELD repl I'd basically have to start and stop a PojoCacheSession on the way in and out for each request. Certainly doable. I wonder though if the overhead of managing all this exceeds that created by just always setting the option internal before resolving the reference. (Of course don't set it if BR is disabled or autoDataGravitation=true.) Besides the work of setting the option, here's what's wasted if a call hits the DataGravitatorInterceptor for a node that doesn't need gravitation: if (isGravitationEnabled(ctx) && MethodDeclarations.isGetMethod(m.getMethodId())) | { | // test that the Fqn being requested exists locally in the cache. | Fqn fqn = extractFqn(m.getMethodId(), m.getArgs()); | if (log.isTraceEnabled()) log.trace("Checking local existence of fqn " + fqn); | if (BuddyManager.isBackupFqn(fqn)) | { | log.info("Is call for a backup Fqn, not performing any gravitation. Direct calls on internal backup nodes are *not* supported."); | } | else | { | if (cache.peek(fqn, false) == null) One thing I notice here is my statement last night about gravitation occuring on a put seems incorrect (see first if statement). I don't know if something changed, or if my year old memory of the issues I was seeing with BR when used for session repl is faulty. There were definitely problems related to greatly excessive gravitation calls that were solved by setting autoDataGravitation=false and using the option. I'll have a look at the old forum posts; IIRC Manik and I sorted it out on the forums. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4056918#4056918 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4056918

18 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Annotation Deployer

by bill.burke＠jboss.com

I want to create two deployers. * An annotation deployer that creates a map of Javassist ClassFile objects for all classes in the Deployment Unit's classpath and attaches this map to the DeploymentUnit. Annotation driven deployers like EJB3, would use this cache to scan for annotations. This deployer exists solely for performance reasons. We don't want more than one deployer scanning and reparsing .class files to create Javassist objects just to figure out whether it should process the archive. Another feature of the deployer woudl be the ability to fine tune scanning. - A META-INF/.noscan file. If this file exists in the archive, the annotation deployer will not create the javassist cache. (no scanning) - A META-INF/.ignore-scan file that allows you to list archives you don't want scanned. * The second deployer is just to clean up this cache. I've had a few people complain about boottime performance both on forums and support cases. This would help to alleviate this problem. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4056908#4056908 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4056908

18 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: dataflow integration

by msandoz

thanks for the encouraging and informative replies. i will begin working on this next week. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4056903#4056903 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4056903

18 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums June 2007