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

[Design of JBoss Transaction Services] - Re: transaction support in JBossAS 5.0

by mark.little＠jboss.com

"reverbel" wrote : "mark.little(a)jboss.com" wrote : Yes, but in TP systems you never take a chance, no matter how small. Plus, I'm sure someone made a similar comment about date fields back in the 1960's and looks what happened come the year 2000! ;-) | Now your argument sounds a bit like a rhetorical one, as the year 2000 issue was an entirely different problem! ;-) | Yes and no. anonymous wrote : | Unless you use unbounded transaction ids you will be always taking a chance, which of course should be very, very, very small. Since the XA spec places an upper limit on the size of Xids, there is no way around this in the XA design space. It is really a matter of reaching a point that is safe enough. | This is interesting ;-) If we used 128 bit encoding then we could address every atom in the universe uniquely. Most schemes don't use that approach, XA being one of them. Most Uids are federated implementations, where uniqueness is guaranteed within the scope of a domain. The way XA was supposed to work was to use an approach similar to DNS, and approach a body like IANA where companies could get their own high-order bits for the Xid that would be unique to them. Then they only had to ensure that the low-order bits were unique within their own domain. Unfortunately thay didn't really take off. anonymous wrote : | Half a million years at one million TPS is certainly safe enough. Note that this would not be an upper limit on the entire lifetime of the TP system, but just on the time a transaction may remain in the active state or in a heuristically completed (and not yet forgotten) state. In other words, it is just an upper limit on the time any given transaction may exist in the current set of transaction log files. Half a million years is actually way over the top for that; a few months would probably be enough. | | I understand "long transactions" are becoming increasingly important, but... Do you really expect them to be that long? ;-) | | Regards, | | Francisco Hey, we shouldn't rule anything out ;-) However, although I understand why you're doing this reference approach, I'm not convinced it buys you much. The size of an IOR is so large anyway when compared to an Xid, that saving a few bytes is unlikely to make much of a difference on the number of blocks that get written in the log. It's the number of physical disk blocks and not the amount of information, that makes a difference. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977175#3977175 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977175

19 years, 6 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: crash during heapSnapshot()

by kabir.khan＠jboss.com

You probably need to increase the size of your heap using the -Xmx option View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977173#3977173 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977173

19 years, 6 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: transaction support in JBossAS 5.0

by mark.little＠jboss.com

"reverbel" wrote : "mark.little(a)jboss.com" wrote : Oh, and I assume you have to durably record the mapping between the short-hand notation (long) and the real transaction id. Essentially keep a reference as to where your index (the long) has reached so that, upon failure and recovery, you can continue counting from where you left off (or you risk generating a new mapping using the same counter before half a million years is up ;-). This durable recording is going to impose some overhead: every time you increment the counter you have to record it to disk . Plus, it probably needs to be managed transactionally too. Or did I miss something? | | Very good points. Generating local ids with a linear, one-dimensional transaction counter would have these problems indeed. Fortunately, a high/low approach works well here. Below I describe the one implemented by the old TM code in JBoss AS. (That part of the code is not actually old, BTW. It was written about one year ago). | | Split the 64-bit counter in two parts: a high part with (say) 20 bits, and a low part with 44 bits. Whenever you need to generate a new local transaction id, you increment just the low part, without durably recording its value. Whenever the TM (re)starts, you increment the high part and durably record its new value. Thus the (durable) high part counts TM restarts and the (non-durable) low part counts transactions in a TM run. With this solution, the overhead per transaction is just the cost of an in-memory increment. The downside, of course, is a significant reduction on the maximum time any given transaction may exist in the current set of transaction log files, but half a million years was too much anyway. :-) | | Regards, | | Francisco | Funnily enough we used to do something very similar in the Rajdoot RPC mechanism back in 1984 for orphan detection and elimination in the distributed environment. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977170#3977170 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977170

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Once and only once delivery?

by timfox

Added task http://jira.jboss.com/jira/browse/JBMESSAGING-604 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977158#3977158 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977158

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Detection of duplicate messages

by timfox

If we want duplicate detection to work between failures of the jms client then we need to do it on the server side. It also needs to work between failures of the server so needs to be persisted in persistent storage. This is certainly going to be a performance drag so I suggest we add a feature request for it, and it to be off by default. We should probably implement it by keeping a cache of message or transaction id. The entries time out and are evicted after a certain amount of time which can be specified by the client. As genman has pointed out, this is not a common feature in messaging systems so I am not too worried if we don't implement this immediately. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977154#3977154 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977154

19 years, 6 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: crash during heapSnapshot()

by halset

Even if jboss-profiler webapp mdo not hang forever, it does not manage to do the complete analyse. I guess this is related to the java crash while doing heapSnapshot() Clicking into "ClassRefs" for the classes that are using the most memory result in pages with empty tables. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977151#3977151 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977151

19 years, 6 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: ProcessDefinition with no startTask

by mteira

Thanks a lot for all your comments. So, conceptually, are these scenarios valid: 1.-A ProcessDefinition with no start task. 2.-A ProcessDefinition with start task without a related form. Are they supported? Regards. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977147#3977147 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977147

19 years, 6 months

1
0
0 / 0

[Design of JBoss Portal] - needing help for News Portal

by neisan9

Dear Developers I want to create a News Portal for a university site with JAVA. therefore I select JBOSS Portal for this job. please let me know is this portal practical for my situation or if you know a better news portal with JAVA please loffer it to me thanks for your kind attention View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977144#3977144 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977144

19 years, 6 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: running jboss profiler under SolarisX86 on 64-bit JVM

by ramazanyich

I tired compile.sh from linux64 directory and with library which is compiled using this script 64-bit JVM works !! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977142#3977142 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977142

19 years, 6 months

1
0
0 / 0

[Design of JBoss Profiler] - crash during heapSnapshot()

by halset

Hello. I am trying to debug a memory leak. JBoss are started with -agentlib:jbossAgent. Doing a forceGC() works. Doing heapSnapshot() produces those huge files and then the JBossService just dies. I then restart the service and try to process the lof files from the jboss-profiler webapp. Sometimes it works, other times it just hangs forever. I am using java 1.5.0, jboss-profiler 1.0CR4, jboss-4.0.2, windows 2000 sp 4. Thanks. - Tore. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977140#3977140 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977140

19 years, 6 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 October 2006