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

[Design of POJO Server] - Re: Running with the full featured profile service

by bytor99999

Is there any update on this? I saw a check-in for profileservice-beans.xml, but I haven't seen an update to the repo beans xml file to allow AS5 to startup with the Profile Service. Thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064629#4064629 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4064629

18 years, 8 months

1
0
0 / 0

[Design of JBossCache] - New Locking Strategy Proposal for JBoss Cache

by jason.greene＠jboss.com

Hello everyone, I would like your feedback on a new locking strategy design. This design, if ratified, would be targeted for a future version of JBoss Cache (not 2.0.0) Modern databases are able to achieve high concurrency by ensuring that readers are never blocked by writers. Our current pessimistic locking strategy does not offer this precondition, which leads to poor performance (lock contention, upgrade exceptions, timeouts, etc) when there is a mixture of reads and writes on the same node (Pretty much the use case of PojoCache). Also, the current pessimistic model also has a dirty-read race condition with READ COMMITTED. Optimistic locking solves the concurrency problems by implementing full MVCC, this however has other problems. It has memory overhead, since every tx has to keep its own node copy. It can't be used with write locks on reads (SELECT FOR UPDATE, Option.setForceWriteLock()) and for the same reason it can't implement the SERIALIZATION isolation level. Last, it has to prevent overwrites (rollback exception), which while useful in some cases, it's not always the desired behavior. My proposed solution is capable of all isolation levels, high read concurrency, and has a relatively low memory footprint. This is done by using limited global versioning with write locking, and MVCC for reads: An incoming reader is notated as R, a writer as W, the current version as v, and the node state is a function N(v). Essentially at any given time a reader will see N(v). Once a write occurs, we copy the node, N(v)' which only the writer sees. So in short we have: R = N(v) W = N(v)' There can only ever be one writer (one write lock), so therefore only one instance of N(v)'. This gives us the essential property "readers never blocked by writers" as well as prevents dirty reads. Once the writer TX commits, the new version is visible to new readers, this will of course require a short lived atomic operation for the swap, which gives us READ COMMITTED: N(v + 1) = N(v)' v = v + 1 If REPEATABLE READ is desired, on the first read of a node, the TX holds a reference to that specific version (this is just a reference! no copying, so everyone that hits the same version shares the same version), z. This version is used for all read calls, until either a write occurs within the same TX or the TX ends. z = v RR = N(z) When a RR TX obtains a write lock on a node we toss the stale version, N(z), (which is eventually GCd). The same semantics in READ COMMITTED are followed, N(v)' is created as a copy of N(v). Reads and writes from the write lock holding TX then use N(v)' This gives us SELECT FOR UPDATE. READ UNCOMMITTED can be implemented by either substituting READ COMMITTED (which is allowed), or by not creating an N(v)' for writes as an optimization. SERIALIZABLE can be implemented by just obtaining a write lock on all reads, N(v)' is not needed as well. So, in summary, all isolation modes with the exception of SERIALIZABLE will never block on another TX for a read (unless setForceWriteLock() is used on the read). Memory footprint will only be 1 additional copy per active writer in READ COMMITTED, and in the case of REPEATABLE READ only 1 additional copy per write commit that is visible to a reading TX. I created a nice table to outline the differences between the previous locking modes, and this proposal. I refer to the proposal as NL (New Locking) | Item PL OL NL | --------------------------------------------------------------- | Non-Blocking Reads N Y Y | All Isolation Modes Y[1] N[2] Y | SELECT FOR UPDATE Y N Y | Prevents write-skew in RR Y Y Y (Optional) | Low memory overhead Y N Y | No comparison phase Y N Y | No copy on read Y N Y | No copy on write Y N Y (Only RU + S) | Fail-fast version checking N/A N Y (Optional) | | | 1. READ COMMITTED has to use a RW lock to be reliable, | this isn't the case now (dirty read race). | 2. SERIALIZABLE is not possible | Thoughts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064626#4064626 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4064626

18 years, 8 months

1
0
0 / 0

[Design of JBoss Build System] - Re: jboss-head build testsuite action plan

by bill.burke＠jboss.com

do we want to disable broken tests and create jira tasks for them? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064595#4064595 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4064595

18 years, 8 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Optimizing genrated advisors

by kabir.khan＠jboss.com

I've improved the configuration of the stress framework. See https://svn.jboss.org/repos/jbossas/projects/aop/trunk/aop/src/test/org/j... for available properties. It now consists of several levels, if found at a given level it will use that value, otherwise it will hit the next level. The levels are: 1) System Properties, i.e. -Dwarmup=500 2) Single Test configuration, e.g. src/resources/test/stress/simple/SimpleReflectToJavassistTestCase_testException.properties would configure properties for just that test 3) TestCase configuration, e.g. src/resources/test/stress/simple/SimpleReflectToJavassistTestCase.properties would configure defauls for all tests within that test case 4) Global stress defaults, configured in src/resources/test/stress/config.properties https://svn.jboss.org/repos/jbossas/projects/aop/trunk/aop/src/resources/... 5) Hardcoded default values in DefaultScenarioPropertyReader View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064592#4064592 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4064592

18 years, 8 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Reorganizing clustering testsuite

by bstansberry＠jboss.com

Another thing that would help is being able to specify in jboss-web.xml what cache to use. Right now it's fixed. This would eliminate the need to stop and restart the servers in order to test REPL-SYNC, FIELD, non-default BuddyReplication, etc. All these variations are really variations on the cache config. Rather, the test would deploy an appropriate cache into the standard server configs and the test wars would use it. At this point a stop and restart of the 2 cluster nodes is roughly a 5 min process. That should drop as AS 5 gets more polished, but eliminating all the restarts will save a lot of time. The above is further down the road though. Should be done as part of an overall solution to intelligent webapp cache deployment, one that includes the ability to deploy the cache as an intrinsic part of the webapp deployment. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064587#4064587 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4064587

18 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Providing bean name aware feature

by adrian＠jboss.org

"alesj" wrote : | Did we ever considered similar scanning for 'MC beans' as it exists for EJB3 and Seam? That can be done when Bill adds his generic scanner to the deployers. i.e. have a deployer that instead of using a -beans.xml creates mc deployment components (BeanMetaData) from what the scanner found. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064576#4064576 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4064576

18 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Providing bean name aware feature

by alesj

"adrian(a)jboss.org" wrote : Just add support for an annotation. | There's no reason to force people to program in xml. | I'll add them both - xml is OOTB. The annotation will be part of whole annotation handling impl. "adrian(a)jboss.org" wrote : | All of the stuff that can be done with XML, should be doable with annotations. | In principle, all that should be in the xml is a list of beans | with the xml just used to override the annotations or when the bean is not annotated. I agree. Did we ever considered similar scanning for 'MC beans' as it exists for EJB3 and Seam? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064571#4064571 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4064571

18 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Missing artifact breaking build

by adrian＠jboss.org

No just an oversight on my part. :-) Should be there now. http://snapshots.jboss.org/maven2//jboss/jboss-classloading-spi/5.0.0-SNA... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064568#4064568 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4064568

18 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Missing artifact breaking build

by alesj

Is this intentional? Not yet commiting all the stuff - being forced by Sacha. :-) | [WARNING] Unable to get resource 'jboss:jboss-classloading-spi:jar:5.0.0-SNAPSHOT' from repository jboss-snapshots (http://snapshots.jboss.org/maven2) | [INFO] ------------------------------------------------------------------------ | [ERROR] BUILD ERROR | [INFO] ------------------------------------------------------------------------ | [INFO] Failed to resolve artifact. | | Missing: | ---------- | 1) jboss:jboss-classloading-spi:jar:5.0.0-SNAPSHOT | | Try downloading the file manually from the project website. | | Then, install it using the command: | mvn install:install-file -DgroupId=jboss -DartifactId=jboss-classloading-spi \ | -Dversion=5.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file | | Path to dependency: | 1) org.jboss.microcontainer:jboss-classloader:jar:2.0.0-SNAPSHOT | 2) jboss:jboss-classloading-spi:jar:5.0.0-SNAPSHOT | | ---------- | 1 required artifact is missing. | | for artifact: | org.jboss.microcontainer:jboss-classloader:jar:2.0.0-SNAPSHOT | | from the specified remote repositories: | central (http://repo1.maven.org/maven2), | jboss-snapshots (http://snapshots.jboss.org/maven2), | repository.jboss.org (http://repository.jboss.org/maven2/), | snapshots.jboss.org (http://snapshots.jboss.org/maven2/), | jboss (http://repository.jboss.org/maven2) | | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064560#4064560 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4064560

18 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Providing bean name aware feature

by adrian＠jboss.org

Just add support for an annotation. There's no reason to force people to program in xml. All of the stuff that can be done with XML, should be doable with annotations. In principle, all that should be in the xml is a list of beans with the xml just used to override the annotations or when the bean is not annotated. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064552#4064552 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4064552

18 years, 8 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 July 2007