November 2006 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Usage of OID on ConnectionFactories

by timfox

You don't want to use client id. That's not a unique id for the connection factory, it's an identifier for the user. Also the mbean name won't work. How does the client know this? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989198#3989198 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989198

19 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: HAConnectionFactory UseCase question

by timfox

I is preferable since we get a smoother distribution of connections across machines (assuming the same smooth load balancing policy is used in both I and II) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989197#3989197 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989197

19 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Problems with replicating entity queries via JBC

by max.andersen＠jboss.com

Hi Brian, The important part of querycaching is updatetimestampscache which does require replication - otherwise hibernate will not be able to decide wether a result in the query cache is out-of-date or not. So it should be ok (i guess) :) Manik, Bela, Galder and I had a talk during JBW which I hope Manik will soon send out his notes for. The results of that meeting would probably help fix some of these things to. Saying that, I'm surprised to hear that JBC isn't able to use the applications current thread context classloader ?! I thought this were the way these serilaization issues were solved before ? Note, I don't think the serialization issues only occur for querycache - it would AFAIK also occur if a user has his own UserType in the id of his entities. /max View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989195#3989195 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989195

19 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Web Console: Context Menus and Navigation

by kukeltje

Tom, I agree, I misinterpreted David's 'disabled'. MyFaces also has a 'rendered=true/false' which would do the job. You should not have lots of disabled menuitems if you are a regular user. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989185#3989185 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989185

19 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jBPM 3.2 web-console not working?

by kukeltje

use whatever jsf ide you want to manipulate the forms after they have been generated by the gpd. I personally use exadel View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989182#3989182 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989182

19 years, 4 months

1
0
0 / 0

[Design of JBossCache] - EvictionPolicy methods

by genman

I noticed that nobody seems to use EvictionPolicy methods such as getChildrenNames(), hasChild(), getCacheData(), etc. It might make sense to simply remove these methods and add a EvictionPolicy { Cache getCache(); } . Change EvictionPolicy.configure() to EvictionPolicy.setCache() to match... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989169#3989169 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989169

19 years, 4 months

1
0
0 / 0

[Design of JBossCache] - JBCACHE-880 discussion ...

by genman

I came with a new Eviction strategy. The idea is to allow users to "put" an expiration time into a Node, and the cache will then evict the node at that time. I went ahead and commited the changes already, but I'm not 100% pleased yet. The things that I am not happy with are: 1. I used "Long(timestamp)" as the expiration time. It would make more sense ot have expiration indicated with a java.util.Date instead, except Date is a (little) heavier and not constant. 2. Most of the time, users want to use a relative time, e.g. 10 seconds or 10 days. 3. Expiration is indicated with a String field "expiration". (Although it's configurable, I don't see why people would want to change this.) Getting this string constant out results in code that looks kind of crappy. Ideally, it would be better to have an API, such as: Node.setTimeToLive(int amount, TimeUnit unit); If this were Ruby, I'd add this method to the object at runtime. :-) Anyway, perhaps this belongs in a Util class or a static method on some existing class? Thoughts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989165#3989165 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989165

19 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - Problems with replicating entity queries via JBC

by bstansberry＠jboss.com

Using JBC as a 2nd level cache leads to problems deserializing user classes when the Hibernate query cache is enabled. See http://jira.jboss.com/jira/browse/JBCLUSTER-150 for details. This is really a JBC/Hibernate issue, although workarounds are possible in EJB3. Since any solution impacts EJB3, and any very short term workaround (i.e. for a December stacks release) is only possible in EJB3, I'm discussing the issue here. Issue is JBC's classloader is from server/all/lib, and thus can't see and deserialize classes that are loaded from deploy. Deserialization happens when Hibernate's use of JBC as 2nd level cache causes replication. Specifically: 1) The Hibernate query cache is used. Here a user class could end up being used as an argument in a query. Hibernate replicates the actual query as the part of the FQN of a node in JBC. 2) A custom class is used as a field in an entity, and its not mapped as a component, but rather Hibernate treates it as a BLOB. The custom class would be replicated. (I haven't actually confirmed this failure mode, but it quite likely exists.) Solutions: A) Register a classloader with JBC for a region of the cache. JBC exposes an API to allow this to happen. The Hibernate/JBC integration code (part of Hibernate) can be updated to take advantage of this API. Hibernate already has the logical concept of different cache regions; the integration code can be updated to register the thread context classloader with JBC when a region is created. EJB3 already partially overrides the standard Hibernate/JBC integration code, so as a short term workaround it's possible to fix this in EJB3, pending a later Hibernate release with this fixed. Problems with solution A): i) Hibernate has a "default" query cache region that will be shared by all queries that don't specifically name a region. There is no foolproof way to assign a specific classloader to this region, since it's storing to a JBC instance that may be shared between multiple EJB deployments. The cache region can be specified by users, although it's ugly: | @Entity | @Cache (usage=CacheConcurrencyStrategy.TRANSACTIONAL) | @NamedQueries({ | @NamedQuery(name="account.highbalance.default",query="select account.balance from Account as account where account.accountHolder = ?1 and account.balance > ?2"), | @NamedQuery(name="account.highbalance.namedregion",query="select account.balance from Account as account where account.accountHolder = ?1 and account.balance > ?2", | hints={@QueryHint(name="org.hibernate.cacheRegion",value="AccountRegion")}) | }) | public class Account implements Serializable | { | ... | } | The second query above uses the named region. ii) With the query cache, the custom class is actually part of the Fqn of a JBC node, rather than part of its data map. I realized over the weekend that the existing JBC code for handling region-based classloaders doesn't handle custom classes in an Fqn. JIRA to remove this limitation is http://jira.jboss.com/jira/browse/JBCACHE-876, which should be pretty straightforward. But, fixing it requires JBC 1.4.1.GA, which is likely at least a couple weeks away. Bringing us to solution.. B) Don't replicate the query cache. Hibernate provides a hook to specifying the factory class used to set up any query cache. In persistence.xml we can specify a custom query cache factory that integrates with JBC, but which instructs JBC not to replicate any writes for that region of the cache. Thus the query cache is a local only cache, while entities are replicated. Hibernate also has an "UpdateTimestampsCache", which is used to trigger invalidations of query cache entries. AFAIK, there is no replication problem with this cache, and it needs to remain replicated. I've pinged the Hibernate guys re: any issues w/ not replicating the query cache. Solution B can also be implemented in the EJB3 code base pending a better solution in a Hibernate release. If there is an immediate requirement to get a workaround for this problem, it's the only way I see to go. Another long term possibility is solution... C) Like A), but now we create one JBC entity cache per deployment (i.e. per Hibernate session factory) rather than a single shared cache. This avoids the problem of deciding what classloader to use for the "default" query cache -- there's only one classloader per cache instance. With the JGroups multiplexer, having numerous JBC instances is a workable option. But going this route requires more thought. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989163#3989163 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989163

19 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Usage of OID on ConnectionFactories

by clebert.suconic＠jboss.com

Clebert wrote : Also.. that will be an issue when a customer is upgrading his version.. A customer would need to define the ClientID or the ConnectionFactory won't work, but we will have an exception clearing that. We could take the action of using a sequence case clientID is null (something we will have to think about later). | Please, scratch that.. I was so tired that I didn't realized that the clientID defined on ConnectionFactory was being used to automatically define clientIDs (connection.setClientID). I'm now using a different String for that. I'm using the ConnectionFactory's MBean name. If we don't want to use that string we will have to ellect another string for that. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989161#3989161 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989161

19 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: HAConnectionFactory UseCase question

by bstansberry＠jboss.com

Option II implies that the client has connected to a JNDI service that provides a proxy with load balancing behavior (e.g. HA-JNDI). That may not be the case. It is not at all a requirement to use HA-JNDI to access clustered services (e.g. clustered EJBs) -- the HA aspect of the JNDI service and the HA aspect of the service being looked up are completely orthogonal. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989160#3989160 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989160

19 years, 4 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 November 2006