January 2008 - jboss-dev-forums - Jboss List Archives

[Design of JBossCache] - Re: Implicit marshalled values - a better way of handling re

by manik.surtani＠jboss.com

"manik.surtani(a)jboss.com" wrote : | | +100. Hugely limiting in the way we have to support custom objects in Fqns right now. | And slow too. A large percentage of time spent marshalling calls is spent marshalling Fqns as individual elements so we can allow for custom objects. I'd like to make this a priority for 3.x, to restrict Fqn elements to {String, byte, short, int, long, float, double, char, boolean}. Thoughts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117089#4117089 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117089

16 years, 4 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Sending an Oracle JMS message to the ESB

by tschungelbuch

I would like to use the oracle database job functionality to send on execution time a oracle aq jms message to the esb in order to execute the action list defined in the jboss-esb.xml. I have an esb up and running using the schedule provider, but I would like to replace it by the above to overcome the unnecessary db polling. But I have so far never worked with the oracle aq jms tools. If you have samples on how to setup the oracle side to send messages to the esb would be very much appreciated. Please let me know, if you need further information. Kind regards RH View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117088#4117088 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117088

16 years, 4 months

1
0
0 / 0

[Design of JBossCache] - Re: Local changes on direct custom object or collection refe

by manik.surtani＠jboss.com

Interesting that we have not seen this as an "issue" in the past. I'd venture to say that this is a language issue (feature?) the programmer needs to be aware of and deal with accordingly. The same as adding objects to any container - a collection, thread local, etc. Parallels could even be drawn to passing object references into methods as parameters. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117087#4117087 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117087

16 years, 4 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Maven ESB plugin

by tobysaville

Hello, has this plugin moved recently? should it not be in the following location: http://snapshots.jboss.org/maven2/org/jboss/maven/plugins/maven-jboss-esb... cheers, toby View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117084#4117084 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117084

16 years, 4 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Sending an Oracle JMS message to the ESB

by kurt.stam＠jboss.com

Sorry not sure I follow.. can you explain a little more? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117082#4117082 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117082

16 years, 4 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Sending an Oracle JMS message to the ESB

by tschungelbuch

Dear Kurt Do you have also samples from the oracle side? Kind regards RH View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117079#4117079 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117079

16 years, 4 months

1
0
0 / 0

[Design of JBossCache] - Local changes on direct custom object or collection referenc

by galder.zamarreno＠jboss.com

Yesterday, one of our consultants (Chris Harris) brought up a very interesting point regarding local changes on direct custom object or collections references that are cached: anonymous wrote : I have a customer who is trying to use TreeCache 1.4 directly and our doing something like : (Note I am writing this code directly in this case so it may not compile ;-) ): | | //within the transaction | | List aList = new ArrayList(); | aList.add("Test1"); | tree.put("/a/b/c", "name", aList); | | aList.add("Test2"); | | //transaction commit | | //outside the transaction | | aList.add("Test3"); | | They are experiencing that if they add something to the List within the cache after the put then the new element within the list is also cached. I would have not expected this as I always thought you need to explicitly call put to add the object back into the cache. | | They are also experiencing that "Test3" is also added the the cache but is not replicated until the next transaction is commits. Again I don't think this is right. | | The design of their application involves putting a layer in front of TreeCache that exposes simple put and get methods to the users of their API. They are considered that users may now be adding data to the cache that they did not intend to add. | | Can someone validate if this is the expected behavior of TreeCache. | | The workaround I have is to clone the object before giving it back to the client but they is not a very nice solution. Here's the response that I gave to him: anonymous wrote : When it comes to standard JBoss Cache usage, transactional work is primarily used to limit replication which is costly. Local changes on direct custom object or collections references will be visible locally. | | When it comes to pessimistic locking, JBossCache maintains a direct reference to the object stored in memory, so adding an element to a list after a put will be visible in the cached element, but the thing to bear in mind is that if transaction commits, it'll get replicated and if it rollbacks, it won't get replicated and the local modifications via put will be rollbacked, in this case, the put will be reverted and won't be visible. | | Even though the changes the cached changes will be visible after "aList.add("Test2");", this will only be visible within that transaction. Locking will prevent that other transactions act on the cached object. | | Same happens with OL even though changes within a transaction are maintained in a workspace. If you're within a transaction and you call get(), the value returned will be looked up in the workspace for the transaction, so in your case, a get call after "aList.add("Test2");" will return a list with Test2 too. We also store direct references to objects in OL's workspaces. | | Outside of a transaction, unless you do a put call, there won't be a replication, which is why adding to a List does not produce a replication. You'd need to use PojoCache to get this type of behavior. Chris is pretty much now forced to clone inputs or returns to the cache to avoid this type of issue. Thoughts? Is this maybe an option we wanna be providing in the future? or is this is an edge case that the user must deal with? In core JBossCache, we have no control over the references to these objects. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117068#4117068 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117068

16 years, 4 months

1
0
0 / 0

[Design of JBossCache] - Re: Problem with after loading Huge data

by manik.surtani＠jboss.com

Please ask such questions in the user forums as this has nothing to do with the design of JBoss Cache. Your use case does sound very interesting though. Ask again on the user forum, I'll answer there. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117044#4117044 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117044

16 years, 4 months

1
0
0 / 0

[Design of JBossCache] - Re: Shutdown hooks

by manik.surtani＠jboss.com

Thinking about it a bit more, and particularly about the comment in the user forum thread to: 1. remove any shutdown hooks in cache.stop() if this is called externally/manually 2. add some intelligence in cache.stop() to detect if it is being called by the shutdown hook and don't remove the shutdown hook in this case With the above, do we then need any sort of manual override regarding the registration of shutdown hooks? Can we not then make do with *always* registering a shutdown hook, and then have the hook unregister if cache.stop() is called manually, or by an MBean server/microcontainer? Saves adding a configuration element. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117041#4117041 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117041

16 years, 4 months

1
0
0 / 0

[Design of JBossCache] - Shutdown hooks

by manik.surtani＠jboss.com

This is in response to a user forum thread http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4089709#4089709 and it's corresponding JIRA JBCACHE-1204. What will happen for JBC 2.1.0.GA is that the default behaviour is: 1. If an MBean server is detected, do not register a shutdown hook. 2. Else, register a shutdown hook. To make things more sophisticated for cases where an MBean server may not control shutdown or a non-MBean server environment may control shutdown (such as a JBoss-MC standalone environment) there is a config parameter: | |  | <attribute name="ShutdownHookBehaviour">DEFAULT</attribute> | | Any thoughts or comments on this? Brian? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4117032#4117032 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4117032

16 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums January 2008