[JBoss-dev] Re: [JBossCMP] why not select for update on entity load?
It would have to be optional behavior (ideally, specified by database, like the type maps), but I think it's a great idea. On Wed, 21 Mar 2001, Bill Burke wrote: Hi all, (Where should I email questions like this? Jboss-Dev, Jboss-User, JBoss-CMP? Thanks) Why not have the ability to "select for update" in CMP for an EntityBean load? I know this is unnessary when only one instance of JBoss is running or if the bean is marked as read-only, but what happens when you have more than one JBoss hitting the DB? Since clustering is not supported, is this a good way to manage multiple instances of JBoss hitting the same datasource? You could make all your connections TRANSACTION_SERIALIZABLE, but doesn't that create performance problems? Also, with serializing, it kind of sucks that the whole transaction is rolled back if one row in one table has serialization issues. Also, maybe "select for update" can be used as an optimization for the LOCKING-WAITING performance problem discussed earlier by Marc and Simone. Regards, Bill -- This is the JBossCMP mailing list. Please send email to '[EMAIL PROTECTED]' with the command 'unsubscribe jbosscmp [email@address]' in the body of the mail to be removed from this list. -- Dan Christopherson (danch) nVisia Technical Architect (www.nvisia.com) Opinions expressed are mine and do not neccessarily reflect any position or opinion of nVISIA. --- If you're a capitalist and you have the best goods and they're free, you don't have to proselytize, you just have to wait. -Eben Moglen ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] EJBHome object creation?
On Mon, 26 Mar 2001, Troy Molander wrote: Hello, I have a purely academic question that is geared towards acquiring a better understanding of how an object can be dynamically generating from nothing more than an interface. At some point (I assume during deployment) the Home interface extending EJBHome is implemented and exported as a UnicastRemoteObject. Exactly how is this object created and the Home interface of the provider bean implemented? JBoss uses the class java.lang.reflect.Proxy to generate proxy implementations of the bean's interfaces. These proxies delegate to an InvocationHandler implementation that JBoss provides. Take a look at the javadoc for those JDK classes: it's almost as cool as doing proxies in Python 8^}) Thanks for any insight, Troy Molander -- Dan Christopherson (danch) nVisia Technical Architect (www.nvisia.com) Opinions expressed are mine and do not neccessarily reflect any position or opinion of nVISIA. --- If you're a capitalist and you have the best goods and they're free, you don't have to proselytize, you just have to wait. -Eben Moglen ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RE: Log4jService rolled into 2.3 core
According to the commit logs that just rolled by, Scott has already copied it over to the 2.2 branch. On Tue, 3 Apr 2001, JbossDev wrote: Download the contrib-cvs.zip, look for the log4j-folder and follow the instructions :-) Knut - Original Message - From: "Grimsæth Christer" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, April 03, 2001 12:44 PM Subject: [JBoss-dev] RE: Log4jService rolled into 2.3 core Can we please have this functionallity in the 2.2 release? -- Christer Grimsæth Consultant TietoEnator Consulting AS, Energy Components. http://www.energy-components.com FROM: Scott M Stark DATE: 04/02/2001 21:02:43 SUBJECT: [JBoss-dev] Log4jService rolled into 2.3 core I integrated Fulco Muriglio's log4j based mbean into the org.jboss.logging package and updated the jboss.conf to make it simple to switch to this as the logging service. It probably should be made the default logging service in the future as the log4j framework is a superset of the JBoss logging. There is nothing that prevents the use of the org.jboss.logging.Log4jService and org.jboss.logging.Log4jServiceMBean classes in any previous version of JBoss so you could grab the source and integrate the mbean into previous versions. The comments in the latest jboss.conf along with the conf/default/log4.properties should be all you need to switch to Log4jService for 2.1+ as the 1.0.4 log4j.jar is already in the distribution. ___ Jboss-development mailing list EMAIL: PROTECTED /contact.php3?[EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development -- Dan Christopherson (danch) nVisia Technical Architect (www.nvisia.com) Opinions expressed are mine and do not neccessarily reflect any position or opinion of nVISIA. --- If you're a capitalist and you have the best goods and they're free, you don't have to proselytize, you just have to wait. -Eben Moglen ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] FW: Busy wait on one thread
On Mon, 11 Jun 2001, Bill Burke wrote: Again, IMHO, these race condition fixes can't wait until JBoss 3.0 since it sounds like 3.0 won't be ready until August/September? I agree with Bill here - the race condition fix really does need to be in 2.4 (maybe even 2.2.x). 3.0 Should get a more aggressive rewrite of the synchronization interceptor (multiple instances per bean, etc.) -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ROWID: Final Call :(
go ahead and commit. On Tue, 10 Jul 2001, Vinay Menon wrote: Hello guys, Has anyone had the chance to take a look at the ROW ID thingey I had posted [3 times!]. I have not heard back from anyone and think that if we are NOT interested I should stop posting this question over and over again. Vinay ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development -- Dan Christopherson (danch) nVisia Technical Architect (www.nvisia.com) Opinions expressed are mine and do not neccessarily reflect any position or opinion of nVISIA. --- If you're a capitalist and you have the best goods and they're free, you don't have to proselytize, you just have to wait. -Eben Moglen ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/readahead/META-INF jaws.xml
User: danch Date: 01/10/28 16:04:56 Modified:src/resources/readahead/META-INF Tag: Branch_2_4 jaws.xml Log: test ordered findall Revision ChangesPath No revision No revision 1.1.2.2 +1 -1 jbosstest/src/resources/readahead/META-INF/jaws.xml Index: jaws.xml === RCS file: /cvsroot/jboss/jbosstest/src/resources/readahead/META-INF/jaws.xml,v retrieving revision 1.1.2.1 retrieving revision 1.1.2.2 diff -u -r1.1.2.1 -r1.1.2.2 --- jaws.xml 2001/07/09 01:06:08 1.1.2.1 +++ jaws.xml 2001/10/29 00:04:56 1.1.2.2 @@ -7,7 +7,7 @@ finder namefindAll/name query / -order / +ordername/order read-aheadtrue/read-ahead /finder finder ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/readahead/ejb CMPFindTestSession.java
User: danch
Date: 01/10/28 16:04:27
Modified:src/main/org/jboss/test/readahead/ejb Tag: Branch_2_4
CMPFindTestSession.java
Log:
test ordered findAll
Revision ChangesPath
No revision
No revision
1.1.2.2 +25 -18
jbosstest/src/main/org/jboss/test/readahead/ejb/CMPFindTestSession.java
Index: CMPFindTestSession.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/readahead/ejb/CMPFindTestSession.java,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -u -r1.1.2.1 -r1.1.2.2
--- CMPFindTestSession.java 2001/07/09 01:06:05 1.1.2.1
+++ CMPFindTestSession.java 2001/10/29 00:04:26 1.1.2.2
@@ -2,6 +2,7 @@
import java.util.Iterator;
import java.util.Collection;
+import java.text.Collator;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.ejb.EJBException;
@@ -15,17 +16,17 @@
/**
* Implementation class for session bean used in read-ahead finder
* tests
- *
+ *
* @author a href=mailto:[EMAIL PROTECTED];danch (Dan Christopherson/a
- * @version $Id: CMPFindTestSession.java,v 1.1.2.1 2001/07/09 01:06:05 starksm Exp $
- *
+ * @version $Id: CMPFindTestSession.java,v 1.1.2.2 2001/10/29 00:04:26 danch Exp $
+ *
* Revision:
*/
public class CMPFindTestSession implements SessionBean {
private static final int DATASET_SIZE = 100;
-
+
private SessionContext sessionContext;
-
+
public void ejbCreate() {
}
public void ejbRemove() {
@@ -37,23 +38,23 @@
public void setSessionContext(SessionContext context) {
sessionContext = context;
}
-
+
public void removeTestData() {
try {
InitialContext ctx = new InitialContext();
CMPFindTestEntityHome home =
(CMPFindTestEntityHome)ctx.lookup(CMPFindTestEntity);
-
+
Collection coll = home.findAll();
Iterator iter = coll.iterator();
while (iter.hasNext()) {
CMPFindTestEntityRemote rem = (CMPFindTestEntityRemote)iter.next();
-
+
rem.remove();
}
} catch (Exception e) {
}
}
-
+
public void createTestData() {
try {
InitialContext ctx = new InitialContext();
@@ -62,7 +63,7 @@
for (int i=0;iDATASET_SIZE;i++) {
String key = Long.toString(System.currentTimeMillis());
CMPFindTestEntityRemote rem = home.create(key);
-rem.setName(Name);
+rem.setName(Name+i);
rem.setRank(Rank);
rem.setSerialNumber(123456789);
//give him an address
@@ -78,12 +79,12 @@
throw new EJBException(e.getMessage());
}
}
-
+
public void addressByCity() {
try {
InitialContext ctx = new InitialContext();
AddressHome home = (AddressHome)ctx.lookup(Address);
-
+
long startTime = System.currentTimeMillis();
Collection coll = home.findByCity(Eau Claire);
int count = 0;
@@ -100,12 +101,12 @@
System.out.println(Caught +e);
}
}
-
+
public void testByCity() {
try {
InitialContext ctx = new InitialContext();
CMPFindTestEntityHome home =
(CMPFindTestEntityHome)ctx.lookup(CMPFindTestEntity);
-
+
long startTime = System.currentTimeMillis();
Collection coll = home.findByCity(Eau Claire);
int count = 0;
@@ -125,15 +126,21 @@
try {
InitialContext ctx = new InitialContext();
CMPFindTestEntityHome home =
(CMPFindTestEntityHome)ctx.lookup(CMPFindTestEntity);
-
+
long startTime = System.currentTimeMillis();
Collection coll = home.findAll();
int count = 0;
Iterator iter = coll.iterator();
+ String lastName = 0;
+ Collator collator = Collator.getInstance();
while (iter.hasNext()) {
CMPFindTestEntityRemote rem = (CMPFindTestEntityRemote)iter.next();
-rem.getName();
+String thisName = rem.getName();
+if (collator.compare(lastName,thisName)=0)
+ throw new EJBException(Ordering of findAll failed:
+lastName++thisName);
+//System.out.println(lastName=+lastName+,
thisName=+thisName+);
//System.out.println(Name: +rem.getName()+ Rank: +rem.getRank());
+lastName = thisName;
count++;
}
long endTime = System.currentTimeMillis();
@@ -141,12 +148,12 @@
} catch (Exception e) {
}
}
-
+
public
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCDefinedFinderCommand.java JDBCFindEntitiesCommand.java
User: danch
Date: 01/10/28 16:03:06
Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc Tag: Branch_2_4
JDBCDefinedFinderCommand.java
JDBCFindEntitiesCommand.java
Log:
Fixed bug with empty query strings. This also fixes issues with order being ignored
for findAll. Odd upshot is that you can make 'findAll' not be a true findAll.
Revision ChangesPath
No revision
No revision
1.14.2.5 +5 -2
jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCDefinedFinderCommand.java
Index: JDBCDefinedFinderCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCDefinedFinderCommand.java,v
retrieving revision 1.14.2.4
retrieving revision 1.14.2.5
diff -u -r1.14.2.4 -r1.14.2.5
--- JDBCDefinedFinderCommand.java 2001/07/14 21:43:24 1.14.2.4
+++ JDBCDefinedFinderCommand.java 2001/10/29 00:03:06 1.14.2.5
@@ -28,7 +28,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Michel de Groot/a
* @author a href=mailto:[EMAIL PROTECTED];Vinay Menon/a
* @author a href=mailto:[EMAIL PROTECTED];danch (Dan Christopherson/a
- * @version $Revision: 1.14.2.4 $
+ * @version $Revision: 1.14.2.5 $
*/
public class JDBCDefinedFinderCommand extends JDBCFinderCommand
{
@@ -110,7 +110,10 @@
if (lcQuery.startsWith(where))
whereClause = query;
else
-whereClause = where +query;
+if (query.trim().length() != 0)
+ whereClause = where +query;
+else
+ whereClause = ;
}
1.10.2.2 +20 -24
jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCFindEntitiesCommand.java
Index: JDBCFindEntitiesCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCFindEntitiesCommand.java,v
retrieving revision 1.10.2.1
retrieving revision 1.10.2.2
diff -u -r1.10.2.1 -r1.10.2.2
--- JDBCFindEntitiesCommand.java 2001/09/10 21:06:01 1.10.2.1
+++ JDBCFindEntitiesCommand.java 2001/10/29 00:03:06 1.10.2.2
@@ -33,7 +33,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];Joe Shevland/a
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
- * @version $Revision: 1.10.2.1 $
+ * @version $Revision: 1.10.2.2 $
*
* pbRevisions:/b
*
@@ -46,27 +46,27 @@
public class JDBCFindEntitiesCommand implements JPMFindEntitiesCommand
{
// Attributes
-
+
private JDBCCommandFactory factory;
private HashMap knownFinderCommands = new HashMap();
-
+
// Constructors --
-
+
public JDBCFindEntitiesCommand(JDBCCommandFactory factory)
{
this.factory = factory;
-
+
// If finder method uses custom implementation, then it is used. This
overrides
// defined and automatic finders.
Class ejbClass = null;
try {
- ejbClass =
+ ejbClass =
factory.getContainer()
.getClassLoader()
.loadClass(factory.getMetaData().getEntity().getEjbClass());
Method[] customMethods = ejbClass.getMethods();
-
+
for (int i = 0; i customMethods.length; i++)
{
Method m = customMethods[i];
@@ -87,25 +87,21 @@
}
// Make commands for the defined finders
-
+
Iterator definedFinders = factory.getMetaData().getFinders();
while(definedFinders.hasNext())
{
FinderMetaData f = (FinderMetaData)definedFinders.next();
-
+
if ( !knownFinderCommands.containsKey(f.getName()) )
{
JPMFindEntitiesCommand finderCommand = null;
-if (f.getName().equals(findAll)) {
- finderCommand = factory.createFindAllCommand(f);
-} else {
- finderCommand = factory.createDefinedFinderCommand(f);
-}
-
+finderCommand = factory.createDefinedFinderCommand(f);
+
knownFinderCommands.put(f.getName(), finderCommand);
}
}
-
+
// Make commands for any autogenerated finders required
Method[] homeMethods;
Method[] localHomeMethods;
@@ -163,26 +159,26 @@
}
}
-
+
// JPMFindEntitiesCommand implementation -
-
+
public FinderResults execute(Method finderMethod
Re: [JBoss-dev] Backend session information - Tx - Data distribution
You could also you JMS with XA - send messages out containing whatever you need to track. This will be sent iff the transaction commits. You can then write an MDB (or any other listener) to take the messages and do whatever you want with them. You actually could (maybe) make the offline clients registered listeners on the topic(s) - that way when they connect they should get all of the messages sent since their last connect. JMS experts, correct me if I'm out of line, here. -danch David Jencks wrote: I'm still a little unclear about what you want. I think it is to be notified right after every transaction commits. Unfortuneately there is no way to register a listener with the tx manager for all transactions. I think the simplest ways to do this are: if you use only cmt, no bmt, modify the tx interceptor to call something after (successful) commit If you use bmt as well, modify the tx manager to notify you. david jencks On 2002.06.06 02:29:52 -0400 Keysers, Wonne wrote: Hi, I already asked this question on the user-list, but got not a single answer. Could somebody help me please? I want to create something which keeps track of some backend session information, for data distribution purposes to offline clients. In that session-info are things like the user logged in, data sharing information (some distribution of data is use case specific, most are DB based though), etc. It is important that data is distributed only when the container transaction commits. What's the best way to do this? Create an MBean, just like the TxManager works, with a ThreadLocal variable? What will happen with the transaction information of that current thread (ThreadInfo inside the TxManager) in this case? Also, is it possible to lookup the current transaction or transactionID or info or transaction information? Thanks in advance for any tips! Wonne !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 3.2//EN HTML HEAD META HTTP-EQUIV=Content-Type CONTENT=text/html; charset=US-ASCII META NAME=Generator CONTENT=MS Exchange Server version 5.5.2654.19 TITLEBackend session information - Tx - Data distribution/TITLE /HEAD BODY PFONT SIZE=2Hi, /FONT /P PFONT SIZE=2I already asked this question on the user-list, but got not a single answer. Could somebody help me please?/FONT /P PFONT SIZE=2I want to create something which keeps track of some backend session information, for data distribution purposes to offline clients./FONT/P PFONT SIZE=2In that session-info are things like the user logged in, data sharing information (some distribution of data is use case specific, most are DB based though), etc.nbsp; It is important that data is distributed only when the container transaction commits./FONT/P PFONT SIZE=2What's the best way to do this?/FONT /P PFONT SIZE=2Create an MBean, just like the TxManager works, with a ThreadLocal variable? /FONT BRFONT SIZE=2What will happen with the transaction information of that current thread (ThreadInfo inside the TxManager) in this case? /FONT/P PFONT SIZE=2Also, is it possible to lookup the current transaction or transactionID or info or transaction information?/FONT /P BR PFONT SIZE=2Thanks in advance for any tips!/FONT /P PFONT SIZE=2Wonne/FONT /P /BODY /HTML ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] WHOEVER BROKE HEAD PLEASE FIX IT!!!!!!!!!!!!!!!
marc fleury wrote: Drugs, Heck James is in Atlanta, and so am I we should get together for some serious Georgia dope smoking. We would connect to the mothership again and we could discuss the state of the world, or at least our industry. I LOVE smoked out sessions. Don't forget Atlanta is the south, the capital of the religious south. The city is beautiful, and at least where I live in Buckhead you have a high-rise and a church, and then another high rise and then another church. That is just the way the city is it is the religious capital of the US. SO yeah G-Zeus and Fuck in the same sentence trigger parse exceptions left and right. marcf PS: murder? what's murder doing in your list, Andy, is that you? is that an LA thing? I cannot parse murder and love and peace in the same sense as you do obviously I think he was referring to the bible, which does have all of the things he listed. Great first novel, too bad we don't have any other writings by that author. danch If you need a therapy read the bible and enjoy sex, drugs, murder and some love and peace. Afterwards four letter words are that wild anymore. Have fun - Andy - Original Message - *From:* James Mitchell mailto:[EMAIL PROTECTED] *To:* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] *Sent:* Wednesday, July 03, 2002 12:34 PM *Subject:* RE: [JBoss-dev] WHOEVER BROKE HEAD PLEASE FIX IT!!! You guys are something else. Jesus 'quoted' and F#CK ME in the same thread. I've always felt that JBoss was not just an app server, but also a religious experience, but JEZZZ ;) I need therapy now thanks. James Mitchell Software Engineer\Struts Evangelist Struts-Atlanta, the Open Minded Developer Network http://www.open-tools.org/struts-atlanta -Original Message- *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]*On Behalf Of *Andreas Schaefer *Sent:* Wednesday, July 03, 2002 3:02 PM *To:* [EMAIL PROTECTED] *Subject:* Re: [JBoss-dev] WHOEVER BROKE HEAD PLEASE FIX IT!!! Hi Geeks I think Scott broke it and he is away (like other did beforehand). Who is without sin throws the first stone grin/. Andy - Original Message - *From:* marc fleury mailto:[EMAIL PROTECTED] *To:* Jboss-Development@Lists. Sourceforge. Net mailto:Jboss-Development@Lists. Sourceforge. Net *Sent:* Wednesday, July 03, 2002 8:56 AM *Subject:* [JBoss-dev] WHOEVER BROKE HEAD PLEASE FIX IT!!! FUCK ME! THIS THING IS DOWN FOR THE PAST 2 DAYS, WHO BROKE HEAD??? PLEASE FIX IT!! --- This sf.net email is sponsored by:ThinkGeek No, I will not fix your computer. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] WHOEVER BROKE HEAD PLEASE FIX IT!!!!!!!!!!!!!!!
Err. Uhmm. See, I'm not really american, ahhh... No, I'm like Canadian, eh? -danch (blushing in collective shame) Christian Riege wrote: hi, On Wed, 2002-07-03 at 23:24, James Mitchell wrote: ou pour nos amis hollandais Ich mag nackt (bildlich sprechend) in die Weiden der offenen Quelle laufen excuse me? as a german i take this as a personal offense being compared to a nation that couldn't even qualify for the world cup. dutch != deutsch of course the comparison was done by an american so i'll let this pass. what you get fed on CNN regarding geography is a shame anyways: http://mitglied.lycos.de/Pedde1/american_geography.jpg sacha will find the link interesting i guess. rgds, christian p.s.: ;) --- This sf.net email is sponsored by:ThinkGeek No, I will not fix your computer. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Oh, it's good to be a geek. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] is x++ an atomic operation??
Being a lazy programmer, I've always found that if I'm spending my few remaining neurons trying to figure out what operation is truly atomic and what isn't, I'll be better off designing the system in such a way that it doesn't matter. I've spent enough time grovelling through disassembled compiler output trying to figure out how Visual C++ had screwed me this time to never want to go through the experience again. Put another way - the fact that you need to know if an operation is atomic means that you have a critical section. Since you have a critical section, synchronize it and keep it short. -danch Dain Sundstrom wrote: Hiram, I this code is at least 2 operations. Most of the atomic operations (except int assignment) are completely useless because you can't both invoke the operator and get the result in a single operation. For example: a: increment i (i=1) b: increment i (i=2) a: assign i to out (out = 2) b: assign i to out (out = 2) This discussion and the tx discussion are both running in the dark; you don't know where you are and you don't know where you are going... work for work sake. If you synchronized the code, what is the actual performance impact? I can tell you that with Hot Spot the code is very little. The real cost happens when you have lots of contention. Do you have lots of contention for this code? I always say synchronize it and if it is a real performance problem we will fix it during tuning. -dain Hiram Chirino wrote: Quick question for you Java Language Gurus out there, I heard one that the post increment operator was an atomic operation. For example, if you have a multi-threaded application with: id=lastRequestId++; You would not need to put this in a synchronized block be cause the ++ would be atomic and thus you would not get 2 duplicate ids. I was wondering if this is true or not. Can anybody confirm this for me?? Regards, Hiram --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty/src/main/org/jboss/jetty JBossUserRealm.java
User: danch
Date: 02/02/22 11:24:03
Modified:jetty/src/main/org/jboss/jetty Tag: Branch_2_4
JBossUserRealm.java
Log:
beautified and back-ported the fix for the 'not serializable' problem from the 3.0
main
Revision ChangesPath
No revision
No revision
1.2.2.5 +136 -159 contrib/jetty/src/main/org/jboss/jetty/Attic/JBossUserRealm.java
Index: JBossUserRealm.java
===
RCS file:
/cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/Attic/JBossUserRealm.java,v
retrieving revision 1.2.2.4
retrieving revision 1.2.2.5
diff -u -r1.2.2.4 -r1.2.2.5
--- JBossUserRealm.java 2 Dec 2001 02:08:53 - 1.2.2.4
+++ JBossUserRealm.java 22 Feb 2002 19:24:03 - 1.2.2.5
@@ -5,7 +5,7 @@
* See terms of license at gnu.org.
*/
-// $Id: JBossUserRealm.java,v 1.2.2.4 2001/12/02 02:08:53 starksm Exp $
+// $Id: JBossUserRealm.java,v 1.2.2.5 2002/02/22 19:24:03 danch Exp $
package org.jboss.jetty;
@@ -26,165 +26,142 @@
/** An implementation of UserRealm that integrates with the JBossSX
* security manager associted with the web application.
* @author [EMAIL PROTECTED]
- * @version $Revision: 1.2.2.4 $
+ * @version $Revision: 1.2.2.5 $
+ *
+ * pbRevisions:/b
+ *
+ * pb20020220 danch:/b
+ * ul
+ * li beautified 8^})/li
+ * li Back-port '... not Serializable ' fix by Anatoly Akkerman
+ * /ul
*/
-public class JBossUserRealm
- implements UserRealm
-{
- private Category _log;
- private String _realmName;
- private AuthenticationManager _securityMgr;
- private RealmMapping _realmMapping;
- private HashMap_users = new HashMap();
-
- class User
-extends SimplePrincipal
-implements UserPrincipal
- {
-User(String name)
-{
- super(name);
- _log.info(Security- created JBossUserRealm::User: +name);
-}
-
-public boolean
- equals(Object o)
-{
- if (o==this)
- return true;
-
- if (o==null)
- return false;
-
- if (getClass()!=o.getClass())
- return false;
-
- String myName =this.getName();
- String yourName=((User)o).getName();
-
- if (myName==null yourName==null)
- return true;
-
- if (myName!=null myName.equals(yourName))
- return true;
-
- return false;
-}
-
-public boolean
- authenticate(String password, HttpRequest request)
-{
- boolean authenticated = false;
- String userName = this.getName(); // needs disambiguation
-
- // Get the JBoss security manager from the ENC context
- if(_securityMgr!=null _securityMgr.isValid(this, password))
- {
- authenticated = true;
- _log.info(Security- User: +userName+ is authenticated);
- SecurityAssociation.setPrincipal(this);
- SecurityAssociation.setCredential(password.toCharArray());
- }
- else
- {
- _log.warn(Security- User: +userName+ is NOT authenticated);
- }
-
- return authenticated;
-}
-
-public boolean
- isUserInRole(String role)
-{
- boolean isUserInRole = false;
- String userName = this.getName();
-
- // Get the JBoss security manager from the ENC context
- SimplePrincipal rolePrincipal = new SimplePrincipal(role);
- Set requiredRoles = Collections.singleton(rolePrincipal);
- if(_realmMapping.doesUserHaveRole(this, requiredRoles))
- {
- isUserInRole = true;
- _log.info(Security- User: +userName+ is in Role: +role);
- }
- else
- {
- _log.warn(Security- User: +userName+ is NOT in Role: +role);
- }
-
- return isUserInRole;
-}
-
-public UserRealm
- getUserRealm()
-{
- return JBossUserRealm.this;
-}
- }
-
- public
-JBossUserRealm(Category log, String realmName)
- {
-_log = log;
-_realmName = realmName;
-_log.info(Security- created JBossUserRealm: +_realmName);
- }
-
- public String
-getName()
- {
-return _realmName;
- }
-
- /**
- * @deprecated
- */
- public UserPrincipal
-getUser(String userName, HttpRequest request)
- {
-return getUser(userName);
- }
-
- //
-
- private synchronized User
-ensureUser(String userName)
- {
-User user = (User)_users.get(userName);
-
-if (user==null)
-{
- user=new User(userName);
- _users.put(userName, user);
-}
-
-return user;
- }
-
- public UserPrincipal
-getUser(String userName)
- {
-if
[JBoss-dev] CVS update: contrib/jetty/src/build build.bat build.sh
User: danch Date: 02/02/22 11:40:34 Modified:jetty/src/build Tag: Branch_2_4 build.bat build.sh Log: made these work better with the current build.xml Revision ChangesPath No revision No revision 1.2.2.2 +33 -32contrib/jetty/src/build/Attic/build.bat Index: build.bat === RCS file: /cvsroot/jboss/contrib/jetty/src/build/Attic/build.bat,v retrieving revision 1.2.2.1 retrieving revision 1.2.2.2 diff -u -r1.2.2.1 -r1.2.2.2 --- build.bat 15 Sep 2001 13:14:59 - 1.2.2.1 +++ build.bat 22 Feb 2002 19:40:34 - 1.2.2.2 @@ -1,32 +1,33 @@ -@echo off -REM $Id: build.bat,v 1.2.2.1 2001/09/15 13:14:59 jules_gosnell Exp $ - -if not exist %JBOSS_HOME%\bin\run.jar ( -echo $JBOSS_HOME/bin/run.jar does not exist -echo set JBOSS_HOME to your JBoss dist directory -exit 1 -) -if not exist %JETTY_HOME%\lib\org.mortbay.jetty.jar ( -echo %JETTY_HOME%/lib/org.mortbay.jetty.jar does not exist -echo set JETTY_HOME to your Jetty3 directory -exit 1 -) - -if not exist %JETTY_EXTRA%/jmx/lib/org.mortbay.jetty.jmx.jar ( -echo %JETTY_EXTRA%/jmx/lib/org.mortbay.jetty.jmx.jar does not exist -echo set JETTY_EXTRA to your Jetty3Extra directory -exit 1 -) - -SET CLASSPATH=..\..\build\classes -SET CLASSPATH=%CLASSPATH%;..\..\..\tomcat\lib\ant.jar -SET CLASSPATH=%CLASSPATH%;..\..\..\tomcat\lib\javac.jar -SET CLASSPATH=%CLASSPATH%;%JBOSS_HOME%\lib\jaxp.jar -SET CLASSPATH=%CLASSPATH%;%JBOSS_HOME%\lib\crimson.jar -SET CLASSPATH=%CLASSPATH%;%JBOSS_HOME%\lib\jboss-jaas.jar -SET CLASSPATH=%CLASSPATH%;%JBOSS_HOME%\lib\ext\jbosssx.jar -SET CLASSPATH=%CLASSPATH%;%JETTY_EXTRA%\jmx\lib\org.mortbay.jetty.jmx.jar - -SET OPTS= -Djetty.home=%JETTY_HOME% -Djboss.home=%JBOSS_HOME% -Djetty.extra=%JETTY_EXTRA% -java %OPTS% org.apache.tools.ant.Main %* - +@echo off +REM $Id: build.bat,v 1.2.2.2 2002/02/22 19:40:34 danch Exp $ + +if not exist %JBOSS_HOME%\bin\run.jar ( +echo $JBOSS_HOME/bin/run.jar does not exist +echo set JBOSS_HOME to your JBoss dist directory +goto done +) +if not exist %JETTY_HOME%\lib\org.mortbay.jetty.jar ( +echo %JETTY_HOME%/lib/org.mortbay.jetty.jar does not exist +echo set JETTY_HOME to your Jetty3 directory +goto done +) + +if not exist %JETTY_EXTRA%/jmx/lib/org.mortbay.jetty.jmx.jar ( +echo %JETTY_EXTRA%/jmx/lib/org.mortbay.jetty.jmx.jar does not exist +echo set JETTY_EXTRA to your Jetty3Extra directory +goto done +) + +SET CLASSPATH=..\..\build\classes +SET CLASSPATH=%CLASSPATH%;..\..\..\tomcat\lib\ant.jar +SET CLASSPATH=%CLASSPATH%;..\..\..\tomcat\lib\javac.jar +SET CLASSPATH=%CLASSPATH%;%JBOSS_HOME%\lib\jaxp.jar +SET CLASSPATH=%CLASSPATH%;%JBOSS_HOME%\lib\crimson.jar +SET CLASSPATH=%CLASSPATH%;%JBOSS_HOME%\lib\jboss-jaas.jar +SET CLASSPATH=%CLASSPATH%;%JBOSS_HOME%\lib\ext\jbosssx.jar +SET CLASSPATH=%CLASSPATH%;%JETTY_EXTRA%\jmx\lib\org.mortbay.jetty.jmx.jar + +SET OPTS= -Djetty.dist=%JETTY_HOME% -Djboss.dist=%JBOSS_HOME% -Djetty.jmx=%JETTY_EXTRA% +java %OPTS% org.apache.tools.ant.Main %* + +:done \ No newline at end of file 1.4.2.2 +3 -3 contrib/jetty/src/build/Attic/build.sh Index: build.sh === RCS file: /cvsroot/jboss/contrib/jetty/src/build/Attic/build.sh,v retrieving revision 1.4.2.1 retrieving revision 1.4.2.2 diff -u -r1.4.2.1 -r1.4.2.2 --- build.sh 15 Sep 2001 13:14:59 - 1.4.2.1 +++ build.sh 22 Feb 2002 19:40:34 - 1.4.2.2 @@ -1,5 +1,5 @@ #! /bin/sh -# $Id: build.sh,v 1.4.2.1 2001/09/15 13:14:59 jules_gosnell Exp $ +# $Id: build.sh,v 1.4.2.2 2002/02/22 19:40:34 danch Exp $ if [ ! -f $JBOSS_HOME/bin/run.jar ] then @@ -33,8 +33,8 @@ CLASSPATH=$CLASSPATH:$JETTY_JMX/lib/org.mortbay.jetty.jmx.jar exec java\ --Djboss.home=$JBOSS_HOME\ --Djetty.home=$JETTY_HOME\ +-Djboss.dist=$JBOSS_HOME\ +-Djetty.dist=$JETTY_HOME\ -Djetty.jmx=$JETTY_JMX\ -classpath $CLASSPATH\ org.apache.tools.ant.Main\ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCInitCommand.java
User: danch
Date: 02/02/25 09:18:20
Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc Tag: Branch_2_4
JDBCInitCommand.java
Log:
made 'table not created' message error rather than debug
Revision ChangesPath
No revision
No revision
1.12.6.6 +182 -172
jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCInitCommand.java
Index: JDBCInitCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCInitCommand.java,v
retrieving revision 1.12.6.5
retrieving revision 1.12.6.6
diff -u -r1.12.6.5 -r1.12.6.6
--- JDBCInitCommand.java 9 Dec 2001 00:46:22 - 1.12.6.5
+++ JDBCInitCommand.java 25 Feb 2002 17:18:20 - 1.12.6.6
@@ -1,172 +1,182 @@
-/*
- * JBoss, the OpenSource EJB server
- *
- * Distributable under LGPL license.
- * See terms of license at gnu.org.
- */
-
-package org.jboss.ejb.plugins.jaws.jdbc;
-
-import java.util.Iterator;
-
-import java.sql.Connection;
-import java.sql.PreparedStatement;
-import java.sql.ResultSet;
-import java.sql.SQLException;
-import java.sql.Statement;
-import java.sql.DatabaseMetaData;
-
-
-import org.jboss.ejb.plugins.jaws.JPMInitCommand;
-import org.jboss.ejb.plugins.jaws.metadata.CMPFieldMetaData;
-import org.jboss.ejb.plugins.jaws.metadata.PkFieldMetaData;
-
-/**
- * JAWSPersistenceManager JDBCInitCommand
- *
- * @see related
- * @author a href=mailto:[EMAIL PROTECTED];Rickard Öberg/a
- * @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
- * @author a href=mailto:[EMAIL PROTECTED];Joe Shevland/a
- * @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
- * @author a href=mailto:[EMAIL PROTECTED];Michel de Groot/a
- * @author a href=mailto:[EMAIL PROTECTED];danch (Dan Christopherson/a
- * @version $Revision: 1.12.6.5 $
- *
- * Revision:
- * 20010621 danch: fixed bug where mapping a PK field to a different column name
- *resulted in an improper PK constraint.
- */
-public class JDBCInitCommand
- extends JDBCUpdateCommand
- implements JPMInitCommand
-{
- // Constructors --
-
- public JDBCInitCommand(JDBCCommandFactory factory)
- {
- super(factory, Init);
-
- // Create table SQL
- String sql = CREATE TABLE + jawsEntity.getTableName() + (;
-
- Iterator it = jawsEntity.getCMPFields();
- boolean first = true;
- while (it.hasNext())
- {
- CMPFieldMetaData cmpField = (CMPFieldMetaData)it.next();
-
- sql += (first ? : ,) +
-cmpField.getColumnName() + +
-cmpField.getSQLType();
-
-
- first = false;
- }
-
- // If there is a primary key field,
- // and the bean has explicitly pk-constrainttrue/pk-constraint in jaws.xml
- // add primary key constraint.
- if (jawsEntity.hasPkConstraint()) {
- sql += ,CONSTRAINT pk+jawsEntity.getTableName()+ PRIMARY KEY (;
- for (Iterator i = jawsEntity.getPkFields();i.hasNext();) {
-String keyCol = ((PkFieldMetaData)i.next()).getColumnName();
-sql += keyCol;
-sql += i.hasNext()?,:;
- }
- sql +=);
- }
-
- sql += );
-
- setSQL(sql);
- }
-
- // JPMInitCommand implementation -
-
- public void execute() throws Exception
- {
- // Create table if necessary
- if (jawsEntity.getCreateTable())
- {
- // first check if the table already exists...
- // (a j2ee spec compatible jdbc driver has to fully
- // implement the DatabaseMetaData)
- boolean created = false;
- Connection con = null;
- ResultSet rs = null;
- try
- {
- con = getConnection();
- DatabaseMetaData dmd = con.getMetaData();
- rs = dmd.getTables(con.getCatalog(), null, jawsEntity.getTableName(),
null);
- if (rs.next ())
-created = true;
-
- rs.close ();
- con.close ();
- }
- catch(Exception e)
- {
-throw e;
- }
- finally
- {
- if(rs != null) try {rs.close(); rs = null;}catch(SQLException e) {}
- if(con != null) try {con.close();con = null;}catch(SQLException e) {}
- }
-
- // Try to create it
- if(created) {
- log.info(Table '+jawsEntity.getTableName()+' already exists);
- } else {
- try
- {
-
- // since we use the pools, we have to do this within
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/metadata CMPFieldMetaData.java
User: danch
Date: 02/02/25 09:17:39
Modified:src/main/org/jboss/ejb/plugins/jaws/metadata Tag: Branch_2_4
CMPFieldMetaData.java
Log:
made some log messages more informative
Revision ChangesPath
No revision
No revision
1.6.4.3 +523 -516
jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/CMPFieldMetaData.java
Index: CMPFieldMetaData.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/CMPFieldMetaData.java,v
retrieving revision 1.6.4.2
retrieving revision 1.6.4.3
diff -u -r1.6.4.2 -r1.6.4.3
--- CMPFieldMetaData.java 20 Nov 2001 09:42:51 - 1.6.4.2
+++ CMPFieldMetaData.java 25 Feb 2002 17:17:38 - 1.6.4.3
@@ -1,516 +1,523 @@
-/*
- * JBoss, the OpenSource EJB server
- *
- * Distributable under LGPL license.
- * See terms of license at gnu.org.
- */
-package org.jboss.ejb.plugins.jaws.metadata;
-
-import java.lang.reflect.Field;
-import java.lang.reflect.InvocationTargetException;
-import java.sql.Types;
-import java.util.ArrayList;
-import java.util.Iterator;
-import java.util.StringTokenizer;
-import org.w3c.dom.Element;
-
-import org.jboss.deployment.DeploymentException;
-import org.jboss.metadata.XmlLoadable;
-import org.jboss.metadata.MetaData;
-import org.jboss.metadata.EjbRefMetaData;
-
-import org.jboss.logging.Logger;
-
-/**
- * This class holds all the information jaws needs to know about a CMP field
- * It loads its data from standardjaws.xml and jaws.xml
- *
- * @see related
- * @author a href=[EMAIL PROTECTED]Sebastien Alborini/a
- * @author a href=mailto:[EMAIL PROTECTED];Dirk Zimmermann/a
- * @author a href=mailto:[EMAIL PROTECTED];Vincent Harcq/a
- * @version $Revision: 1.6.4.2 $
- */
-public class CMPFieldMetaData extends MetaData implements XmlLoadable
-{
- // Constants -
- static Logger log = Logger.getLogger(CMPFieldMetaData.class);
- // Attributes
-
- // the entity this field belongs to
- private JawsEntityMetaData jawsEntity;
-
- // name of the field
- private String name;
-
- // the actual Field in the bean implementation
- private Field field;
-
- // the jdbc type (see java.sql.Types), used in PreparedStatement.setParameter
- private int jdbcType;
- // true if jdbcType has been initialized
- private boolean validJdbcType;
-
- // the sql type, used for table creation.
- private String sqlType;
-
- // the column name in the table
- private String columnName;
-
- private boolean isAPrimaryKeyField;
-
-
- /**
-* We need this for nested field retrieval.
-*/
- private String ejbClassName;
-
- /**
-* We need this for nested fields. We could compute it from ejbClassName on the
fly,
-* but it's faster to set it once and cache it.
-*/
- private Class ejbClass;
-
- /**
-* Is true for fields like data.categoryPK.
-*/
- private boolean isNested;
-
- // Static
-
- // Constructors --
- public CMPFieldMetaData(String name, JawsEntityMetaData jawsEntity) throws
DeploymentException
- {
- this.name = name;
- this.jawsEntity = jawsEntity;
-
- // save the class name for nested fields
- ejbClassName = jawsEntity.getEntity().getEjbClass();
- ejbClassName = jawsEntity.getEntity().getEjbClass();
-
- try
- {
- // save the class for nested fields
- ejbClass =
jawsEntity.getJawsApplication().getClassLoader().loadClass(ejbClassName);
- field = ejbClass.getField(name);
- } catch (ClassNotFoundException e)
- {
- throw new DeploymentException(ejb class not found: + ejbClassName);
- } catch (NoSuchFieldException e)
- {
- // we can't throw an Exception here, because we could have a nested field
- checkField();
- }
-
- // default, may be overridden by importXml
- columnName = getLastComponent(name);
-
- // cannot set defaults for jdbctype/sqltype, type mappings are not loaded yet.
- }
-
-
- // Public
- public String getName()
- { return name; }
-
- public Field getField()
- { return field; }
-
- public int getJDBCType()
- {
- if (! validJdbcType)
- {
- // set the default
- if (field!=null)
-jdbcType =
[JBoss-dev] CVS update: contrib/jetty/src/main/org/jboss/jetty JBossUserRealm.java
User: danch
Date: 02/02/28 11:21:13
Modified:jetty/src/main/org/jboss/jetty Tag: Branch_2_4
JBossUserRealm.java
Log:
finished the 'fix' for the NotSerializableException
Revision ChangesPath
No revision
No revision
1.2.2.6 +7 -5 contrib/jetty/src/main/org/jboss/jetty/Attic/JBossUserRealm.java
Index: JBossUserRealm.java
===
RCS file:
/cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/Attic/JBossUserRealm.java,v
retrieving revision 1.2.2.5
retrieving revision 1.2.2.6
diff -u -r1.2.2.5 -r1.2.2.6
--- JBossUserRealm.java 22 Feb 2002 19:24:03 - 1.2.2.5
+++ JBossUserRealm.java 28 Feb 2002 19:21:13 - 1.2.2.6
@@ -5,7 +5,7 @@
* See terms of license at gnu.org.
*/
-// $Id: JBossUserRealm.java,v 1.2.2.5 2002/02/22 19:24:03 danch Exp $
+// $Id: JBossUserRealm.java,v 1.2.2.6 2002/02/28 19:21:13 danch Exp $
package org.jboss.jetty;
@@ -26,7 +26,7 @@
/** An implementation of UserRealm that integrates with the JBossSX
* security manager associted with the web application.
* @author [EMAIL PROTECTED]
- * @version $Revision: 1.2.2.5 $
+ * @version $Revision: 1.2.2.6 $
*
* pbRevisions:/b
*
@@ -77,12 +77,13 @@
String userName = this.getName(); // needs disambiguation
// Get the JBoss security manager from the ENC context
- if (_securityMgr != null _securityMgr.isValid(this, password)) {
+ SimplePrincipal propogationPrincipal = new SimplePrincipal(userName);
+ if (_securityMgr != null _securityMgr.isValid(propogationPrincipal,
password.toCharArray())) {
authenticated = true;
_log.info(Security- User: +userName + is authenticated);
// work around the fact that we are not serialisable - thanks Anatoly
// SecurityAssociation.setPrincipal(this);
- SecurityAssociation.setPrincipal(new SimplePrincipal(userName));
+ SecurityAssociation.setPrincipal(propogationPrincipal);
SecurityAssociation.setCredential(password.toCharArray());
} else {
_log.warn(Security- User: +userName + is NOT authenticated);
@@ -97,8 +98,9 @@
// Get the JBoss security manager from the ENC context
SimplePrincipal rolePrincipal = new SimplePrincipal(role);
+ SimplePrincipal propogationPrincipal = new SimplePrincipal(userName);
Set requiredRoles = Collections.singleton(rolePrincipal);
- if (_realmMapping.doesUserHaveRole(this, requiredRoles)) {
+ if (_realmMapping.doesUserHaveRole(propogationPrincipal, requiredRoles)) {
isUserInRole = true;
_log.info(Security- User: +userName + is in Role: +role);
} else {
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: [jetty-discuss] HTTP loadbalancing
This is maybe a bit offtopic, and a bit long, but this is one of those serindipitous occasions where a conversation strikes on something somebody else is already working on... Greg Wilkins wrote: + Use java.nio as: * if you care about performance you should be using jdk1.4 anyway * if you want one machine to handle more connections than the sum of all your servers, then java.net.ServerSocket aint going to do the job! * I want to play with nio before I write the NioListener for Jetty! Hmm. I've been writing a sort of general purpose TCP server using the NIO stuff that I'd actually rather like to try grafting onto the front end of Jetty, if you don't mind. Bear in mind that this is fairly early work yet, and there are probably lots of holes. Basically, the way it's structure is there is a Server (MBean) which contains listeners (one for each declared hostname:port). The Server has a single thread that uses an NIO selector to find out when it needs to accept on any of them. The resulting SocketChannels are handed off to a ReaderManager, which chooses a ReaderThread to handle that channel. Each reader thread selects on all of its channels, reads data and delegates to a Protocol implementation to build a Request and put appropriate data into it. Once the request gets to the state HEADERS_READ (the headers have all been read and there is enough there to be dispatched) the Reader thread hands gets a worker thread from a pool and hands the Request off to a ContextManager which uses information from the request to dispatch to the appropriate RequestHandler stack (which is where I _think_ Jetty would come in). When the request needs to be written to its output (because it's buffer is full, or the request has been completely handled) it (carrying its SocketChannel) gets handed off/hands itself to a WriterManager, which chooses a WriteThread to handle it in a similiar non-blocking fashion as the ReaderThread. Note that a POST request (or an SMTP command, or a JBossMQ message on a new protocol, or anything that can distinguish header/envelope from body/payload) can be dispatched and processing can begin while the request body is still being read. Likewise on the output: if the buffer is full, it will start to be written while processing continues. ReaderThreads hold onto SocketChannels until they're closed (to enable keep alive), WriterThreads do not. Direct Byte Buffers are used and pooled wherever possible, allowing the underlying implementation to optimize transfers. I think the biggest advantage here is the level of control it gives administrators over thread usage: you can configure read, write, and work pools separately. One of the things people notice in JBoss under linux is the number of threads used - they'd notice it under Windows or any commercial Unix as well if they looked, it's just that Linux puts its threads right out there for you to see and freak out on in ps and top et. al. Another thought I've had is to use this same framework as the basis for a new invoker for JBoss, so that remote client invocations don't put the server at the mercy of the whims of RMI's thread usage. thoughts, chortels, flames? thanks for your time, danch ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] if you're having trouble building
_not_ pruning empty directories? Is it me, or is the non-existence of an empty directory an exceedingly silly reason for a build to fail? -danch Bill Burke wrote: make sure you're not pruning empty directories. Otherwise, you won't be able to build. I bet this is why the automatic build is failing. Anybody know how to fix the automatic build? Bill ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] is findByPrimaryKey optimization bad?
Bill Burke wrote: A BMP findByPrimaryKey is optimized to look in cache first for the active pk. If it is active in cache, then the pk is just returned, without calling ejbFindByPrimaryKey on the BMP. Should we do this for commit-options 'B' and 'C'? Here's the scenario somebody just submitted as a bug. They get a BMP (so it's active in cash). They manually delete the bean through straight JDBC (not calling bean.remove()). Then findByPrimaryKey(pk) returns a valid Entity when the entity is actually deleted in the DB. Maybe for commit option b and c we should not do this optimization? Same for CMP? What you all think? As I said in a comment on the bug, that optimization breaks many scenarios that force people to use B and C. If the same tables are being used by a legacy application which does deletes, you wind up lying to your users. Bad Thing. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: [JBoss-user] JBOSS 3.x FINAL
I think that documentation for corportate types will always be of the for-pay variety. It just takes too much time to produce that level of documentation, and it also isn't the sort of thing that developers tend to enjoy well enough to donate the required time. Now if anybody knows an open-source minded tech-writer geek, that might be a different story. Really, if you look at any major open-source project, this is true: If you want a well-written guide to how to configure Apache to do various things, you buy a book from O'Reilly. The documentation that's included with Apache is more reference material than anything. And it gets worse from there (look at Tomcat and Struts). I'm sorry to hear that you've had trouble getting at the for-pay documentation: I know others have purchased it without difficulty. There was talk about putting a 'getting started' guide together for free, but I don't think anyone has picked that up. Also, my observation has been that as configuration file formats mature the dtds produced by the JBoss team get better and better as reference material; There are often succinct and informative comments for the less obvious or more important tags. -danch Trawick, James wrote: What I'm really interested in is the more corporate questions (we're still battling for JBoss over Weblogic, and clustering is a real sore point). How does JBoss 3 clustering interact with web container clustering? If they're completely separate (which I'm pretty sure is the case, as it was last time I walked through the code), how can I put together a full clustered J2EE stack with JBoss and (for example) Tomcat/Catalina? To what level does JBoss provide high-availability? What are some failover scenarios? How does one initiate a graceful failover for server maintenance? How flexible/controllable is JBoss clustering in reality? There is nothing about these issues in the online docs, which I've been monitoring pretty closely of late. The forums and the lists are pure and simple information overload, and not always accurate. My point was that there really shouldn't be talk of releasing JBoss 3 for prime time until there's real documentation for us corporate types, and the docs for sale aren't real since they're not really available, at least not to me for whatever reason. I'd be more than happy to help out in documenting all this if somebody would point me in the right direction to find the info. chris -Original Message- From: David Ward [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 14, 2002 1:56 PM To: Trawick, James Cc: 'marc fleury'; Jboss-Development@Lists. Sourceforge. Net; Jboss-User@Lists. Sourceforge. Net Subject: Re: [JBoss-user] JBOSS 3.x FINAL A combination of these has served well enough for me: Online docs: http://www.jboss.org/online-manual/HTML/index.html Forums: http://main.jboss.org/ User List Archive: http://www.mail-archive.com/jboss-user%40lists.sourceforge.net/ David -- Trawick, James wrote: Will the final release actually include documentation? (btw, whoever you went with to sell your JBoss 3 docs should be shot. i went through their process several times, they said they had problems and would get back to me. they never did. just saying that unless JBoss 3 has some form of accessible documentation, i'm afraid that your vision will never come to pass.) chris -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 14, 2002 9:50 AM To: Jboss-Development@Lists. Sourceforge. Net Cc: Jboss-User@Lists. Sourceforge. Net Subject: [JBoss-user] JBOSS 3.x FINAL jboss one is end of march, and we will shoot for mid april for the final release. this gives us 4 weeks gentlemen put your final touches, 4-3-2... marcf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RE: [JBoss-user] JBOSS 3.x FINAL
Very true - the online doc right now says it's for 3.0, but hasn't been completely updated yet. Meanwhile it isn't right for 2.4.x anymore either. Core team members have said that 2.4.x is going to be around for a long time, I think it would behoove us to keep the documentation available, at least as a download. I _believe_ it is branched (or at least tagged) for the 2.4 branch (can't verify, sourceforge is down so I can't browse, behind a firewall, so I can't check through CVS client), so it shouldn't be difficult. -danch David Ward wrote: It doesn't always lag - sometimes it's too eager! Example: I had a gripe that 2.4 documentation started disappering off the web site, being replaced with 3.0 documentation when 3.0 was only alpha. I think that the 2.4 docs should stay available online - at least until 3.x goes final. Mac Rinehart wrote: The free user documentation is only moderately useful, and lags behind development on a number of issues. ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Multiple server configurations
Francisco Reverbel wrote: Isn't Borland dead yet? They're still selling their CORBA implementation? I thought Iona had cornered the market. The commercial market that is. Yes, they are selling it. What I don't know is whether there is anybody buying it or not... :-) Not kidding now: have no info on their market share today. Some time ago they were licensing Visibroker to companies like Oracle and Netscape, which embedded it in their products. Unlike Iona, which always managed to sell Orbix to end users. It's still in Oracle, I believe: a while back I had a conflict between Borland's app server and oracle because oracle had an old version of the visibroker idl2java tool and stuffed it at the head of my path. Borland seems to be selling JBuilder quite a lot, though. It's one of the better IDEs out there. danch ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS locks?
Jason Dillon wrote: I fail to see how you go from CVS to Buildmagic to Ant. --jason Through the one thing that connects the three: Jason Dillon! -danch ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CPU at 99.9 % after completion ofrun-basic-testsuite
If it doesn't calm down, do a thread dump with ctrl-break and see what's going on. -danch Mac Rinehart wrote: Ok, I just finished running the testsuite. And with about 10 minutes passed I am still seeing my CPU maxed out at 100%. Review of active processes shows that java.exe is the primary consumer. This is a Win2k system with a PIII processor, the JBoss build was retrieved about an hour ago. I'll let the computer continue to run and see what happens over time. Mac Rinehart, President Sextant Technology Consulting, Inc SEXTANT TECHNOLOGY CONSULTING is a trademark of Sextant Technology Consulting, Inc. Sextant Technology Consulting, Inc is a provider of enterprise application development services, specializing in J2EE and Oracle technologies. Mac Rinehart is the author of JavaServer Pages For Dummies and Enterprise JavaBeans For Dummies. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Peter Fagerlund Sent: Tuesday, April 09, 2002 4:52 AM To: Mac Rinehart; JBoss development Subject: Re: [JBoss-dev] CPU at 99.9 % after completion ofrun-basic-testsuite on 08-04-2 23.30, Mac Rinehart at [EMAIL PROTECTED] wrote: Haven't actually checked out the CPU usage, Ahhh ... And I've also noticed slowness in other applications after running the testsuite. Could You please check Your CPU before and after running the testsuite ? ... /peter_f ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] 3.0.0 RC1 is available
Prolly not. The sourceforge statistics are updated periodically by a cron job, and are often Just Plain Wrong. sorry. -danch Stephen Davidson wrote: According to SourceForge, there were no downloads of the JBoss3.0RC1 when I started my download. Sounds like I am the first person to grab a copy? -Steve -- Trying to recover from a motherboard meltdown... * * * View thread online: http://main.jboss.org/thread.jsp?forum=66thread=12958 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/readahead/ejb CMPFindTestSession.java
User: danch
Date: 02/04/16 16:06:03
Modified:src/main/org/jboss/test/readahead/ejb Tag: Branch_2_4
CMPFindTestSession.java
Log:
Fixed a bug that was causing tests to error out - seems we're fast enough to insert
1 entity in the windows currentTimeMillis resolution
Revision ChangesPath
No revision
No revision
1.1.2.3 +172 -172
jbosstest/src/main/org/jboss/test/readahead/ejb/CMPFindTestSession.java
Index: CMPFindTestSession.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/readahead/ejb/CMPFindTestSession.java,v
retrieving revision 1.1.2.2
retrieving revision 1.1.2.3
diff -u -r1.1.2.2 -r1.1.2.3
--- CMPFindTestSession.java 29 Oct 2001 00:04:26 - 1.1.2.2
+++ CMPFindTestSession.java 16 Apr 2002 23:06:03 - 1.1.2.3
@@ -1,172 +1,172 @@
-package org.jboss.test.readahead.ejb;
-
-import java.util.Iterator;
-import java.util.Collection;
-import java.text.Collator;
-import javax.naming.InitialContext;
-import javax.naming.NamingException;
-import javax.ejb.EJBException;
-import javax.ejb.SessionBean;
-import javax.ejb.SessionContext;
-import org.jboss.test.readahead.interfaces.AddressHome;
-import org.jboss.test.readahead.interfaces.AddressRemote;
-import org.jboss.test.readahead.interfaces.CMPFindTestEntityHome;
-import org.jboss.test.readahead.interfaces.CMPFindTestEntityRemote;
-
-/**
- * Implementation class for session bean used in read-ahead finder
- * tests
- *
- * @author a href=mailto:[EMAIL PROTECTED];danch (Dan Christopherson/a
- * @version $Id: CMPFindTestSession.java,v 1.1.2.2 2001/10/29 00:04:26 danch Exp $
- *
- * Revision:
- */
-public class CMPFindTestSession implements SessionBean {
- private static final int DATASET_SIZE = 100;
-
- private SessionContext sessionContext;
-
- public void ejbCreate() {
- }
- public void ejbRemove() {
- }
- public void ejbActivate() {
- }
- public void ejbPassivate() {
- }
- public void setSessionContext(SessionContext context) {
- sessionContext = context;
- }
-
- public void removeTestData() {
- try {
- InitialContext ctx = new InitialContext();
- CMPFindTestEntityHome home =
(CMPFindTestEntityHome)ctx.lookup(CMPFindTestEntity);
-
- Collection coll = home.findAll();
- Iterator iter = coll.iterator();
- while (iter.hasNext()) {
-CMPFindTestEntityRemote rem = (CMPFindTestEntityRemote)iter.next();
-
-rem.remove();
- }
- } catch (Exception e) {
- }
- }
-
- public void createTestData() {
- try {
- InitialContext ctx = new InitialContext();
- CMPFindTestEntityHome home =
(CMPFindTestEntityHome)ctx.lookup(CMPFindTestEntity);
- AddressHome addrHome = (AddressHome)ctx.lookup(Address);
- for (int i=0;iDATASET_SIZE;i++) {
-String key = Long.toString(System.currentTimeMillis());
-CMPFindTestEntityRemote rem = home.create(key);
-rem.setName(Name+i);
-rem.setRank(Rank);
-rem.setSerialNumber(123456789);
-//give him an address
-if ((i % 2) ==0) {
- addrHome.create(rem.getKey(), 1, 123 east st., Eau Claire,
WI, 54701);
-} else {
- addrHome.create(rem.getKey(), 1, 123 east st., Milwaukee,
WI, 54201);
-}
- }
- } catch (Exception e) {
- System.out.println(Exception caught: +e);
- e.printStackTrace();
- throw new EJBException(e.getMessage());
- }
- }
-
- public void addressByCity() {
- try {
- InitialContext ctx = new InitialContext();
- AddressHome home = (AddressHome)ctx.lookup(Address);
-
- long startTime = System.currentTimeMillis();
- Collection coll = home.findByCity(Eau Claire);
- int count = 0;
- Iterator iter = coll.iterator();
- while (iter.hasNext()) {
-AddressRemote rem = (AddressRemote)iter.next();
-rem.getCity();
-//System.out.println(Name: +rem.getName()+ Rank: +rem.getRank());
-count++;
- }
- long endTime = System.currentTimeMillis();
- System.out.println(called +count+ beans in +(endTime-startTime)+
ms.);
- } catch (Exception e) {
- System.out.println(Caught +e);
- }
- }
-
- public void testByCity() {
- try {
- InitialContext ctx = new InitialContext();
- CMPFindTestEntityHome home =
(CMPFindTestEntityHome)ctx.lookup(CMPFindTestEntity);
-
- long startTime = System.currentTimeMillis
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCLoadEntityCommand.java
User: danch
Date: 02/04/16 16:10:17
Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc Tag: Branch_2_4
JDBCLoadEntityCommand.java
Log:
merged patch #520200 for bug 517062 (resultset column ordering)
Revision ChangesPath
No revision
No revision
1.11.2.3 +248 -241
jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCLoadEntityCommand.java
Index: JDBCLoadEntityCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCLoadEntityCommand.java,v
retrieving revision 1.11.2.2
retrieving revision 1.11.2.3
diff -u -r1.11.2.2 -r1.11.2.3
--- JDBCLoadEntityCommand.java14 Jul 2001 21:43:24 - 1.11.2.2
+++ JDBCLoadEntityCommand.java16 Apr 2002 23:10:17 - 1.11.2.3
@@ -1,241 +1,248 @@
-/*
- * JBoss, the OpenSource EJB server
- *
- * Distributable under LGPL license.
- * See terms of license at gnu.org.
- */
-
-package org.jboss.ejb.plugins.jaws.jdbc;
-
-import java.lang.reflect.Field;
-import java.lang.reflect.Method;
-
-import java.util.Iterator;
-import java.util.ArrayList;
-import java.util.List;
-import java.util.HashMap;
-
-import java.rmi.NoSuchObjectException;
-import java.rmi.RemoteException;
-import java.rmi.ServerException;
-
-import java.sql.PreparedStatement;
-import java.sql.ResultSet;
-
-import org.jboss.ejb.EntityEnterpriseContext;
-import org.jboss.ejb.plugins.jaws.JAWSPersistenceManager;
-import org.jboss.ejb.plugins.jaws.JPMLoadEntityCommand;
-import org.jboss.ejb.plugins.jaws.metadata.CMPFieldMetaData;
-import org.jboss.ejb.plugins.jaws.metadata.PkFieldMetaData;
-import org.jboss.ejb.plugins.jaws.metadata.JawsEntityMetaData;
-
-/**
- * JAWSPersistenceManager JDBCLoadEntityCommand
- *
- * @see related
- * @author a href=mailto:[EMAIL PROTECTED];Rickard Öberg/a
- * @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
- * @author a href=mailto:[EMAIL PROTECTED];Joe Shevland/a
- * @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
- * @author a href=mailto:[EMAIL PROTECTED];Dirk Zimmermann/a
- * @author a href=mailto:[EMAIL PROTECTED];danch (Dan Christopherson)/a
- * @version $Revision: 1.11.2.2 $
- */
-public class JDBCLoadEntityCommand
- extends JDBCQueryCommand
- implements JPMLoadEntityCommand
-{
- /**what is the position of each cmp field in the generated select statement?
-* this simply maps the position of the field in the CMP list to its position
-* in the generated select statement. This is neccessary because of the variable
-* number of key columns (which are skipped in a load) and because there can
-* be overlap between the two: pkfields and cmpfields are neither disjoint sets
-* nor is the cmpfields a subset of pkfields (not that that makes sense to
-* me right now, but I'll roll with it until I have more chance to analyse -
danch)
-*/
- int [] cmpFieldPositionInSelect = null;
-
- /** This const is used in places where I need to add an offset to a count
-* to account for the fact that JDBC counts from one whilst every other
-* damn thing in the languase starts at 0, the way God intended!
-*/
- private static final int JDBC_WART_OFFSET = 1;
- // Constructors --
-
- public JDBCLoadEntityCommand(JDBCCommandFactory factory)
- {
- super(factory, Load);
-
- String sql = createSelectClause() + FROM + jawsEntity.getTableName()
- + WHERE + getPkColumnWhereList();
- if (jawsEntity.hasSelectForUpdate())
- {
- sql += FOR UPDATE;
- }
-
- setSQL(sql);
- }
-
- protected String createSelectClause() {
- // Select SQL
- String sql = SELECT ;
- HashMap alreadyListed = new HashMap();
- // put the key fields in first
- // we'll stash the column names here so that we can later map an overlapped
- // column (overlap between PK and CMP) into its spot in the select statement.
- String[] pkColumnNames = new String[jawsEntity.getNumberOfPkFields()];
- Iterator keyIt = jawsEntity.getPkFields();
- int fieldCount = 0;
- while (keyIt.hasNext())
- {
- PkFieldMetaData pkField = (PkFieldMetaData)keyIt.next();
-
- sql += ((fieldCount==0) ? : ,) +
-jawsEntity.getTableName() + . + pkField.getColumnName();
- alreadyListed.put(pkField.getColumnName().toUpperCase(), pkField);
- pkColumnNames[fieldCount]=pkField.getColumnName();
- fieldCount++;
- }
-
- cmpFieldPositionInSelect = new int[jawsEntity.getNumberOfCMPFields()];
- Iterator it = jawsEntity.getCMPFields
Re: [JBoss-dev] why storeEntity on a NOT_SUPPORTED method?
The spec says that NOT_SUPPORTED is an optional thing for entities. Frankly, I'm glad that the new stuff doesn't support it - really the bizarre thing is doing anything with a dirty entity outside of a transaction. It means that somebody is bringing in a lot of overhead and not making use of any of it. I think that if you're going to allow this nonsense, though, that storing does follow the principal of least astonishment by extending the equally bletcherous notion of JDBC 'auto-commit'. standard consultant disclaimer: Or not. -danch marc fleury wrote: I know, i agree, but most don't :( the claim (supposedly from the spec) is that the absence of a transaction triggers a storage. If you ask it makes no sense marcf PS: can you get to compile on JDK1.4? |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Bill |Burke |Sent: Monday, April 29, 2002 12:58 PM |To: Jboss-Dev |Subject: [JBoss-dev] why storeEntity on a NOT_SUPPORTED method? | | |Why are we storing a dirty entity when the method call is not called within |the context of a transaction (NOT_SUPPORTED, NEVER, etc...)? Seems kind of |bizarre. | |Bill | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: Oracle doing JBoss
IMO Oracle is the Microsoft of J2EE - so this article on OTN is pretty surprising :) How do you mean 'Oracle is the Microsoft of J2EE'? I don't understand. * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66thread=10212 ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] nightly build is 3.1?
Yup! Scott branched 3.0 off a little while ago, so the head is now 3.1 -danch Bill Burke wrote: EOM ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Anyone doing https in JBoss using jsse ?
Jung , Dr. Christoph wrote: Hi there, snip / *Bummer* I´m thinking about that classloading stuff ALL THE TIME. There must be something else in Java than classloading. *Sigh* I have faith that once enough of the JDK has been rewritten for classloading to actually work right, we'll find something else ;^}) Now we have a workaround, but we do not want to type new URL(https,localhost,42,myFile,new com.sun.net.ssl.internal.www.protocol.https.Handler()) and right. gack. depending our code agains jsse.jar instead of simply writing new URL(https://localhost:42/myFile;). Has anyone already seen this problem and knows how to resolve it? Should we write and install a JBoss-specific URLStreamHandlerFactory in the spine such that we can do the protocol extensions by ourselves and using Thread.currentThread().getContextClassLoader().loadClass() approach once for all modules? org.jboss.util.URLStreamHandlerFactoryThatLoadsTheDamnClassesRight ? I'd imagine it'll be needed in other places, too. -danch ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMX RMI Adapter JNDI binding
You can give the testsuite a .ant.properties file overriding the servername. I've got a config that I use to run marathon on my laptop against my 'big' machine at home. I can send this out this evening, if anyone is interested. Unfortunately I don't have that stuff with me right now. As far as my .02$ on the JNDI name goes, the 'hostname' part really ought to be configurable. The current default is fine, but can we override it? I don't think it matters whether that goes in the middle (as currently) or at the beginning (as Hiram suggests), but having it be configurable is (I think) important. Is there any interaction between this anc clustering? Wow, that killed a lot of electrons for $.02! -danch Francisco Reverbel wrote: On Sun, 12 May 2002, Jason Dillon wrote: Currently we are binding to jmx:hostname:rmi which is fine when you are working with the localhost, but will start to cause problems once used in a multi-host environment. ... So for a client on a remote host to correctly make use of the deployer.sh or any other simialr tool using the jmx adapter it will have to have knowledge of the servers local hostname (as returned by java.net.InetAddress.getLocalHost().getHostName()) and specify that value for --server, then specify -Djava.naming.provider.url=jnp://www.mydomain.com. This may also be an issue if you have a client running in the same host as the server, but on a VM from other vendor. When I run java.net.InetAddress.getLocalHost().getHostName() on a Sun VM, I get something like myhost.mydomain.com. When I do the same thing on an IBM VM for Linux, I get myhost. This appears to be the reason the whole testsuite fails if I use a Sun VM for the server and an IBM VM for the testsuite clients (or vice-versa). Regards, Francisco ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: [JBoss-user] JBoss in a multi developers environment
OK, given the title of this thread, am I the only one who's featuring a bunch of people developing J2EE programs on vt100 terminals? OK, that's a bit ridiculous - XTerms I suppose anyway. Dain Sundstrom wrote: Jules Gosnell wrote: OK - that's not so bad. I can interface Jetty to it - no problem. Well that's one vote. We'll have to wait to see if everyone else agrees. I'm still a little concerned about this centralisation creeping outwards. Are ports the only resource over which different instances of JBoss running on the same box are likely to collide ? I think so, but I don't know. We should also bear in mind that certain services are usually expected on particular ports. Reconfiguring the client side to know where the new port is may be just as important as telling the server side where to listen. I would also like to add server pushed client-side configuration for stuff like ENC, security config, ports, etc.. For all I know it could already be there. For now, they would have to configure the client by hand. One very common case is where the client is a browser - the 'config' is part of the URL. You port service will need to allocate/deallocate and lookup ports (and throw PortAlreadyAllocated and NoSuchPort Exceptions). Or is this becoming too complicated ? Much simpler. It just returns you a port number (int). The service would have to de allocate the port on shutdown (the port service could listen for destroy life cycle event). It has to be able to map the service name to the port in a deterministic fashion, right? Otherwise it's practically useless (stick a random number generator in there and you've done noone any good - you couldn't even use that for development) -danch ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: [JBoss-user] JBoss in a multi developers environment
Mike Finn wrote: I had been working on an alternative solution to this problem (see earlier thread in Mid-April: Multiple Instances). After some thought and work, this (Dain's) seems more robust (at least to me). The other way was effectively a proxy server sitting on a single (known) port, directing streams to the correct endpoints. The problem is that not every wire protocol puts enough (or anything) in the initial packets in the stream to identify the service - so I don't think the proxy would work as we discussed before (HTTP would work OK, but it looks like JNDI and RMI wouldn't). Unfortunately, I didn't do any packet sniffing to find this until I had already written the proxy server/MBean :-(. Q 1) I assume service name would be the JBoss service name? (jmx-html, webserver, etc). IP service name would be insufficient as there are multiple services serving HTTP (webserver, jmx-html, jetty/tomcat). 2) How do clients find what port to which they connect today? For example, w/ a separate-VM-client that does a bean lookup (via configured port - eg 1099) - where does it find the RMI port number(eg ) to make the method call? Is it in the object returned from the JNDI server? (Probably a dumb one, but not obvious to me). I've been assuming that they'd be statically mapped - There are a few things (JNDI and servlet-HTTP at leaast) that have to be consistent from run to run for a particular server config. At that point, a standalone client would mostly need its initial context URL overriden - each developer just keeps their own jndi.properties for such a client? -danch ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: [JBoss-user] JBoss in a multi developers environment
Dain Sundstrom wrote: Mike Finn wrote: Don't know. I would say that the client would need to configure it by hand. This is what you do when you have many developers working on a web app. I know that my server port is 8098. Right, but you don't get that if you hand them out in serial order, do you? I understand that that was a short term thing, I just want to make sure that everyone sees the need to have some things stay the same between server starts. There is most likely a better way, but it is not important right now (we can solve it later). -dain ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: [JBoss-user] JBoss in a multi developers environment
Anatoly Akkerman wrote: mbean code=...ServiceBindingMgr name=...,service=ServiceBindingMgr ... ServerNamestarksm/ServerName /mbean while for your instance he adds: mbean code=...ServiceBindingMgr name=...,service=ServiceBindingMgr ... ServerNamedsundstrom/ServerName /mbean Now there can be a static configuration for our instances for which the client ports, address in use is invariant across instance restarts. Why not let the ServiceBindingManager autogenerate necessary config files for you (like jndi.properties or whatever else is needed)? Then use something (like a simple Java program) that talks to the ServiceBindingManager via JMXConnectors to pull the config files from the ServiceBindingManager before you start your client that uses your personal ServerName. This way, the ports can remain purely dynamic, no need for static configurations. Just my 2c. A great majority of the time, the client will be a web browser. Anatoly. ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Deflating (or creating) a JAR file from a Directory
ant. Use the Source! -danch Andreas Schaefer wrote: Hi Geeks Before I am wasting a lot of time: Does anyone know or know an article how to create the same behaviour programmatically what the JAR tool does ? Thanx x Andreas Schaefer Senior Consultant JBoss Group, LLC x ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-user] RE: [JBoss-dev] Open-Source Fight Flares At Pentagon
Mike Finn wrote: Microsoft also said open-source software is inherently less secure because the code is available for the world to examine for flaws, making it possible for hackers or criminals to exploit them. Proprietary software, the company argued, is more secure because of its closed nature. rant Umm, yah, that's why it took until NT4 for them to fix that neat little LanManager hash issue - where the password hash sent over the LAN was cleartext equivalent. I wonder if Microsoft's developers really believe that it's that hard to reverse engineer weak algorythms. Apparently 'more secure' is equivalent to I can't tell if there are any backdoors because I don't have the source. Maybe, It must be more secure: I can't verify that it's mathematically correct! The same principal is why science done by hermits in mountain hideaways has been so much more influential to modern technology than science done openly in an environment where peer review and reproduction of experimental results is critical to acceptance. pfah! First they take bad engineering (Windows won't run without Internet Explorer) and use it as an excuse for monopolistic practices, and then they take bad security practices (If we tell them how it works, they'll break it) and try to make it a virtue! Hrm... Here's the loaded question for Microsoft's talking heads: If open source security is so bad, why did you use kerberos under Windows 2000? /rant OK, back to work. -danch ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-561683 ] Remove log4j dependency on client side
Jason Dillon wrote: You people are all insane. The size is small, and can be made even smaller if it really needs to be. Having light weight clients does not mean we must drop all client-side logging or hack together our own ultra-minimal logging framework or revert to System.out/printStackTrace garbage. Log4j is small, fast, configurable and just what we need. Sure, but how is it configured for the client? Where do log entries go for the client? On the client machine isn't always the right answer. -danch ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss JMS MDB problems
There have been a lot of bugs fixed in the JMS stuff since 2.4.1. Try upgrading to 2.4.6 or 3.0 - no promises, but that should get you closer. -danch Alexander Balaban wrote: Hi, we are using the JBoss 2.4.1. We are sending messages to the JMS Topic at the rate about 5 msg/sec. There is a standard pool of MDB's registered to this topic. Everything works fine for about three or four days and then the JMS dies without any error message (if we increase the message rate, the JMS dies faster). Last thing before the crash is that a new instance of MDB is created, the constructor is called and that is it. It never receives the message in onMessage(). We were running two test stand-alone JMS clients (without MDB). These clients keep receiving messages. All JMS and MDB configuration is a standard one - coming with the JBoss distribution. We tried to increase a number of threads in the pool (from default 15), but it did not help. I wonder if somebody is familiar with this problem, or even knows the solution. Any help is appreciated. Regards Alex *Alexander Balaban* *Software Designer, Nortel Networks, Management Framework Technology* ( * External:*(613) 763-6303* ESN:* 393-6303* FAX:*(613) 765-7387 * *** [EMAIL PROTECTED]* ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Avoiding big numbers of selects loading EJB cache
Sacha Labourey wrote: Hello, There is currently a JAWS RFE on this particular topic. And I'm working on it. This is taking longer than I'd expected because doing it right is going to effect more of JBoss than i'd anticipated (and more than I'd really like) A couple days more and I should have at least a patch for people to flame me on. And if you want to use this in BMP, I think there is a pattern proposed on theserverside. Having dug through all this code, I believe that the 'fat key' pattern will work in JBoss. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Avoiding big numbers of selects loading EJB cache
Paul Hammond wrote: Hi guys, Just new to this list and JBoss. My question centers around efficient loading of EJBs into JBoss's EJB cache. Normally if you have a finder method, findByXXXYYYZZZ etc, which returns an Enumeration of the EJBs in question, you have a corresponding ejbFindByXXXYYYZZZ method that returns an Enumeration of primary key objects for that particular EJB. My understanding is that the implementation of the findByXXXYYYZZZ method by the container will generally call findByPrimaryKey with the Primary key objects that are returned by ejbFindByXXXYYYZZ one by one to load each EJB if it's not already in the cache. This typically involves an individual select statement from the database etc for each EJB to be loaded. Actually it can get even worse than that: the container's findByXXXYYYZZZ probably won't even call findByPrimaryKey itself, but will allow that to be deferred until such time as the bean is actually accessed. This is a more elegant implementation, since the bean will always have to be checked to see if its state needs loading - avoiding findByPrimaryKey in findByXXXYYYZZZ keeps the load and check in one place. Also, remember that the cache needs to be checked in there as well! If the cache is empty on startup, and you have a finder method returning say 5000 objects, then that will generate 5000 individual selects to the database, not very efficient. I have seen a third party trading system done using BMP on WebLogic whereby initially they have to load up a portfolio of 100,000 trades to run a Risk report on them. Takes about 30 minutes plus to start it up. Not nice. Reporting off of EJBs is probably not the best implementation choice at this point in specdom - you'll be much kinder on your servers if you report the old fashioned way. But yes, this will be very ugly with BMP, no matter what app server you're using. Really what you want is one select statement to get all the relevant information. How do you fit that into the EJB container architecture though? With BMP, you can only cheat. With CMP, the CMP engine can do it. I know O/R tools like TopLink can integrate with say WebLogic so that WebLogic uses TopLink as it's cache. TopLink does support I believe instantion of lots of objects with one query. So you can in effect quickly load the cache. Therefore the container will find all the objects for the primary key are already in the cache and won't call findByPrimaryKey, at least that is my understanding of it, please correct me if I'm wrong here. I'm not sure, but I think it's more likely that WebLogic + TopLink wind up with a two level cache. Now in relation to JBoss, and leaving aside JAWS for a moment because supposing I want to use BMP, how would I do this with JBoss if I didn't want to use a third party O/R tool. You don't want to break the container contract obviously but I can't see how you would avoid doing what the container would do. Here's the sequence of events I would see happening in this hypothetical ejbFindByXXX method Method findByXXX called. Delegated to ejbFindByXXX Select query to database. Iterate through results set. Get the primary key from each row Check if it's in the cache. If it is not, create a new EJB and populate it from the result set and insert it into the cache This you really can't do. The container must be allowed to control the lifecycle of EJB instances. Regardless, add the EJB primary key to the enumeration Return the enumeration Now the container generated method would do pretty much the same thing, but will always find the EJB in the cache because we've put it there, and hence will never call findByPrimaryKey and generate loads o select statements. However we would be messing with the containers cache which is completely outside the contract and we would be duplicating what the container does ourselves, so it's not a satisfactory way of doing things. Is there a legit way of doing this, or is it simply not possible to avoid all those calls to findByPrimaryKey and the associated select statements. See the 'fat-key' pattern on theserverside.com. WARNING: this may significantly degrade JBoss' cache performance! Do you use data access objects? If so, consider creating a static 'read-ahead buffer' in the data access object for a particular entity. Use weak references for the objects, and the PK for the key. in ejbFindByPrimaryKey, check the read ahead before executing SQL. Would JAWS CMP do it efficiently? It will. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Avoiding big numbers of selects loading EJB cache
Sorry to cause confusion by being imprecise. Your post was correct, it's ejbFindByXXX elbLoad (* N) if the beans are uncached or if commit option B or C and the beans have not yet been loaded in the current transaction. Note that commit option B or C and calling the finder from a client with CMT can be (N * M) + 1, where M is the number of methods called! If all N objects are in cache, and commit option is A, there will be only 1 hit to the database. -danch Jay Walters wrote: Maybe I understand less than I think. Are you all saying that the actual scenario is ejbFindByXXX ejbFindByPrimaryKey ejbLoad when the bean needs to be loaded from disk (2N+1) and ejbFindByXXX ejbFindByPrimaryKey (N+1) when the N objects are all already in the app servers cache? ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Compiling error
Are you trying to build with jdk1.2.2? If so, you'll need the optional RMI/IIOP package to get those classes. Better still, upgrade to jdk1.3 Jordi Piñol wrote: Hi, When I compile my application, not found javax.rmi.* and javax.rmi.PortableRemoteObject. I use the next jars: /client/ejb.jar. Which jar has this classes ? -- ·· Jordi Pinyol Essi Projects Ingeniero de Desarrollo [EMAIL PROTECTED]t +34 977 221 182 http://www.essiprojects.com f +34 977 230 170 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
Re: [JBoss-dev] minerva-1_0b3.jar missed in JBoss 2.3 beta?
Minerva has been forked. JBoss (2.3 or later) now uses JBoss-pool, source for which is in CVS at sourceforge. Darius Davidavicius wrote: After i compiled last source code of Jboss server i have found minerva-1_0b3.jar is missed in dist/lib/ext If it is removed? What is replacment for it? if for Jboss 2.1 i was getting oraclePoll like: mbean code=org.jboss.jdbc.XADataSourceLoader name=DefaultDomain:service=XADataSource,name=oraclePool attribute name=PoolNameoraclePool/attribute attribute name=DataSourceClassorg.opentools.minerva.jdbc.xa.wrapper.XADataSourceImpl/attribute Thanks for reply in advance, Darius D ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
Re: [JBoss-dev] Re: [jboss-board] I want to help JBoss!
Sreeram, If you can look at this, it's probably related to some instanceof MarshalledObject checking that I just added. This is probably leading us into the wrong bit of logic somewhere. This _might_ also be dependent somewhat on the database you're running against - This code doesn't like postgres at all, while i've been told it works against Oracle. I'll be looking at this later, as well, so if you do dig into it keep in touch. thanks, Danch Scott M Stark wrote: Start by tracking down the current tracking down the current cmp errors seen in the bank module of the jbosstest suite. There's nothing like jumping into the deep end off of the high dive from the start. - Original Message - From: K S Sreeram [EMAIL PROTECTED] To: Juha Lindfors [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, June 01, 2001 8:37 AM Subject: [JBoss-dev] Re: [jboss-board] I want to help JBoss! I have reasonable experience with database related programming. I would love to help in the jboss-cmp engine, but i have no idea where to begin.. perhaps you or somebody else can guide me on where to begin regarding the jboss-cmp engine Regards KS On Friday 01 June 2001 22:02, you wrote: Hi, I suggest you subscribe to the mailing lists and follow the current development there (especially jboss-dev), pick up what's happening in the discussions and follow the CVS logs. Then when you feel comfortable try development by writing a patch to fix a bug, etc. and gradually move from that to more demanding development. If you have extensive database knowledge, our CMP engine needs help. Also, if writing is your thing, we desperately need people to keep the manuals up to date with the releases. http://www.jboss.org/business/lists.html regards, -- Juha At 20:31 1.6.2001 +0530, you wrote: Hi I am experienced java and j2ee developer, and i am very interested in contributing to the JBoss project. I have used jboss as the j2ee application server for my company's projects. Regards KS To unsubscribe from this group, send an email to: [EMAIL PROTECTED] Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans
It may well be usefull, but does this behavior belong in the normal EntityInstanceInterceptor? Why not just implement an non-blocking variant of EntityInstanceInterceptor, and reconfigure your stack in jboss.xml? K.V. Vinay Menon wrote: OK! I know that it is kind of controversial and that its spec violation and stuff but why can't we have multi threaded beans for read-only cases? Why should we be bothered about transactions? We don't lock the database for selects do we? Non-purists who face real world performance issues - please let me know if these is complete rubbish or is something that 'could' prove useful.. unless someone voluteers to write the code for multiple bean instances per home handle! Vinay Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans
Bill Burke wrote: - What's wrong with doing a Context lock, but not doing a transactional lock for read-only beans? won't you still block on the context lock? If you do this you'll still be spec compliant, correct? How would this affect your performance results? I'm pretty sure the spec says it's up to the Container developer to decide how to synch beans per transaction, but you are required to make EntityBeans single threaded. - Which xml file has the flag (isReadOptimized)? IMHO, if this read-only thing is accepted, this flag for it should be in jboss.xml, not jaws.xml, so that BMP developers have access to it. I agree, if it's there at all. - All in all, IMHO, Transactional EntityBean locking should be removed totally from JBoss. This locking is totally useless when you have more than one instance of JBoss hitting the sam DB anyways. Let the DB handle the locking. If you want your EntityBeans synched across transactions use the select-for-update options if you're using CMP, or with BMP, manage the DB locks yourself. Being able to specify the transaction isolation level for your CMP beans would also let us control concurrent access better. -danch Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
Re: Missing wait/notify (was Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans)
danch (Dan Christopherson) wrote: Georg Rehfeld wrote: One problem here is that when we're waiting on the context, we want to wait on the context (i.e. ctx.wait(DEADLOCKTIMEOUT + 1000)) Just doing wait and notifyAll on the interceptor itself will involve all calls on our entity when we just want to handle contention for the one context. The other problem is that if we're waiting on the transaction, we don't want to do wait/notify on the context - I don't know what we do want to wait on, but we really need to know when the transaction ends. Actually, looking closer at the code, it's probably the mutex that we want to wait on in both cases - it is specific to the key involved. Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans
Bill Burke wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Georg Rehfeld Sent: Wednesday, June 06, 2001 1:11 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans Hello Bill, hi all, - What's wrong with doing a Context lock, but not doing a transactional lock for read-only beans? If you do this you'll still be spec compliant, correct? How would this affect your performance results? I'm pretty sure the spec says it's up to the Container developer to decide how to synch beans per transaction, but you are required to make EntityBeans single threaded. It was reported, that trying to access the beans concurrently without TX and with non-reentrant beans leads to very similar LOCKING-WAITING behaviour as within a TX. But if you access outside a TX AND have the bean reentrant there is no LOCKING-WAITING anymore without any change to existing code. I don't think, this reentrnce really is a problem, data gotten outside a TX must be considered inconsistent anyway, so why not let hundreds of clients do getters concurrently, where is the problem? Concurrent access from clients accessing inside different TXs is still serialized, the only potential danger with reentrant is, when DIFFERENT clients having THE SAME TX access the bean concurrently, how should this normally be possible (except for the allowed callback case)? Before modifying code that makes JBoss incompliant, why not simply use existing spec conform features, it's all there, just use it! - All in all, IMHO, Transactional EntityBean locking should be removed totally from JBoss. This locking is totally useless when you have more than one instance of JBoss hitting the sam DB anyways. Let the DB handle the locking. If you want your EntityBeans synched across transactions use the select-for-update options if you're using CMP, or with BMP, manage the DB locks yourself. Oh, but then you cannot use commit option A anymore. So for A the serialization IS required, and with B and C someone has to implement multiple instances of the bean before removing the locking at container level. Why do you have to implement multiple instances of the bean? For a quick fix, just take out the code that waits for the EntityBean to leave the transaction in EntityInstanceInterceptor. Leave the locking code that comes after the transaction waiting stuff, it's used to make the bean single-threaded(correct?). This will still work for commit-option 'A' won't it? If you keep the bean single-threaded, option 'A' is not violated. What about this scenario: == Transaction A Transaction B Lock Entity B Context Wait for entity b context. Call into business method Modify data Unlock Entity B Context Lock entity B Context Read data A Modified Rollback! = Now transaction B has read data that has never been modified. -danch Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
Re: [JBoss-dev] Fast Updates Based on Row ID
Just for the record, I don't mind having Oracle specific optimizations in JAWS, it's just that the current structure of JAWS does not really lend itself to this. Also, if you do use Oracle specific stuff for this optimization, the option in a jaws entity should be given a name that will tell users clearly that it won't work on other databases. K.V. Vinay Menon wrote: Well, We are an Oracle shop and woudl benefit [like loads of other Oracle users] from these changes. Remember they are there as an option. If you choose not to use them JAWS will work as usual. Vinay - Original Message - From: Jay Walters [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 06, 2001 6:18 PM Subject: RE: [JBoss-dev] Fast Updates Based on Row ID This is oracle specific as far as I know (insert...returning...). The create problem needs to be addressed if one cannot retrieve the rowid, the logic needs to check and see if rowid is set or not - maybe Vinay already did this, I didn't look that hard. Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
Re: Missing wait/notify (was Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans)
I don't understand what is different between the two. Are you saying to
have only one place where we wait? If so I agree.
Bill Burke wrote:
It's not this same. Basically you have a loop to check to see if the
transaction has been commited or unlocked, but you put a wait of 5 seconds
in there. After the 5 seconds if you're still not locked loop again.
OT, how does transaction timeout destroy the thread? TIA.
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of danch
(Dan Christopherson)
Sent: Wednesday, June 06, 2001 3:35 PM
To: [EMAIL PROTECTED]
Subject: Re: Missing wait/notify (was Re: [JBoss-dev] Avoiding Locks for
READ-ONLY Beans)
I think that's roughly equivalent to Georg's 'wait(DEADLOCKTIMEOUT +
1000)'. Did Marc talk about waiting on 'this'? or is that non-literal?
Bill Burke wrote:
I remember Marc talking about this issue awhile back. He said the best
performance would be to have the wait within a loop with a 5
second wait.
while (!locked()) // pseudo code
{
this.wait(5000);
if (!locked())
{
log.(LOCKING-WAITING);
}
}
Regards,
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of danch
(Dan Christopherson)
Sent: Wednesday, June 06, 2001 1:31 PM
To: [EMAIL PROTECTED]
Subject: Re: Missing wait/notify (was Re: [JBoss-dev] Avoiding Locks for
READ-ONLY Beans)
danch (Dan Christopherson) wrote:
Georg Rehfeld wrote:
One problem here is that when we're waiting on the context, we want to
wait on the context (i.e. ctx.wait(DEADLOCKTIMEOUT + 1000))
Just doing
wait and notifyAll on the interceptor itself will involve all calls on
our entity when we just want to handle contention for the one context.
The other problem is that if we're waiting on the transaction, we don't
want to do wait/notify on the context - I don't know what we do want to
wait on, but we really need to know when the transaction ends.
Actually, looking closer at the code, it's probably the mutex that we
want to wait on in both cases - it is specific to the key involved.
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Confidential e-mail for addressee only. Access to this e-mail by anyone else is
unauthorized.
If you have received this message in error, please notify the sender immediately by
reply e-mail
and destroy the original communication.
Re: [JBoss-dev] race condition between EntityInstanceInterceptor and InstanceSynchronization?
Bill Burke wrote: Another possible bug related to this same problem. [please read below]. EntityInstanceInterceptor gets the mutex of the Entity's key before going into the do..while loop. If a different thread/transaction rollsback, the mutex gets detached from the EntityEnterpriseContext and the thread in the do..while loop is acquiring a lock on a context that is not attached. Am I missing something here? I don't think so. Do we need to mark the mutex as invalid? When we add teh wait/notify, invalidation should also notify. I'd really like to go in and fix this problem, but I really need another set of eyeballs to make sure I'm doing things right. Danch, can you volunteer to help? Also, while I'm in this code, maybe I should consider adding the Missing wait/notify and remove that buggy do..while loop as well. I can certainly review. I won't have much time for investigation until this evening, and then my wife may have other plans for my time. -danch Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
Re: [JBoss-dev] ClassCastException: org.opentools.minerva.jdbc.xa.XAPoolDatasourc e
Cast to javax.sql.DataSource, not the XA DataSource. David Cao wrote: Hi, I am trying to access a jdbc pool to MS SQL Server, but I got this problem when I try to cast the ref into XADataSource, I can't find any document or source about org.opentools.minerva.jdbc.xa.XAPoolDataSource, does any one know this problem? Thanks a lot. David Cao - Energizing by Thinking Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
Re: [JBoss-dev] soo... RMI-IIOP
I was doing some thinking on an IIOP invoker a while back. I would have spoken up before now, but I've got plenty to do with JAWS. (more below) Ole Husgaard wrote: Hi, I probably won't find much time for helping out with this, though it is a most interesting project. marc fleury wrote: ah yes then it is much more complicated since we need to have ANY client calling our stuff. Yes, a simple encapsulation of the method invocation over IIOP is quick, but does not ensure interoperability. I agree For interoperability we need to export real CORBA objects, with no special encapsulation. And that is somewhat more complicated. The paper Gerald Brose: Reflection in CORBA, Java and JacORB might be helpful: http://jacorb.inf.fu-berlin.de/~brose/papers/jit98.ps.gz But if possible, we should try not to depend on any particular CORBA implementation. Maybe one day we will even generate stubs and skeletons for IIOP on-the-fly, like Rickard did with dynamic proxies for the JRMP transport. However I would wait with that, even if it means that an external IDL compiler would have to be run at deployment time. Actually, I was looking at the Dynamic Skeleton Interface - we should be able to use it to do without (compiled) skeletons on the server. BTW I will change the invocation layer as part of JBOSS3.0 but will take care of porting anything you have in there, let keep in touch. One thing that would be nice: The ability to have several different transports for invoking the same container. Multiple invokers for the container? I agree! If designed in from the start, I don't think it would complicate or slow down the invocation code. Best Regards, Ole Husgaard. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
Re: [JBoss-dev] ejbStore() delay seems to be a serious problem
The behavior you'd get by setting that flag to false in weblogic would also allow him to not break referential integrity in the case of his transaction. Scott M Stark wrote: Why is this a serious problem? The weblogic docs for the flag you mention indicate the commit is still not done until the end of the transaction and that you would only notice this if your db allows for uncommitted reads. From, http://e-docs.bea.com/wls/docs61///ejb/EJB_environment.html#1048164 Using delay-updates-until-end-of-tx to Change ejbStore() Behavior By default, WebLogic Server updates the persistent store of all beans in a transaction only at the completion (commit) of the transaction. This generally improves performance by avoiding unnecessary updates and repeated calls to ejbStore(). If your datastore uses an isolation level of READ_UNCOMMITTED, you may want to allow other database users to view the intermediate results of in-progress transactions. In this case, the default WebLogic Server behavior of updating the datastore only at transaction completion may be unacceptable. You can disable the default behavior by using the delay-updates-until-end-of-tx deployment element. When you set this element to false, WebLogic Server calls ejbStore() after each method call, rather than at the conclusion of the transaction. Note: Setting delay-updates-until-end-of-tx to false does not cause database updates to be committed to the database after each method invoke; they are only sent to the database. Updates are committed or rolled back in the database only at the conclusion of the transaction. - Original Message - From: David Esposito [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, June 15, 2001 9:01 AM Subject: [JBoss-dev] ejbStore() delay seems to be a serious problem Hello all, I have spent the past few hours reading up on other people with similar problems to mine. So I am familiar with what the EJB spec says (somewhat related to the diamond scenario (11.7.1 of the EJB Spec)) with respect to when a Bean is required to write its data out to persistent storage. However, this seems to be counterintuitive and is a serious problem for operations that manipulate multiple data sources. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
Re: [JBoss-dev] ejbStore() delay seems to be a serious problem
He's not removing the modified bean: he's removing a bean that the modified bean used to refer to. The issue is that the remove causes a data change immediately, while the table behind the modified bean still has the foreign key for the row that's being removed. This violates referential integrity - boom! I thought of suggesting that he put the 'setRecord' method into a RequiresNew transaction, but that would break his transactional semantics (and might deadlock him). I suppose he could just break the remove into a separate transaction, but logically, the code he has is exactly what makes sense as a single transaction. Jay Walters wrote: He wants the update SQL to execute before the remove SQL? The commit isn't the issue, it's the order of operations. What does the spec say about when remove() needs to execute the SQL? My question would be, if the bean has been removed should the persistence manager still be trying to update it? I can understand that one might want to somehow consider side effects, such as a database trigger so maybe one can't optimize out the update. Cheers -Original Message- From: Scott M Stark [mailto:[EMAIL PROTECTED]] Sent: Friday, June 15, 2001 12:38 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] ejbStore() delay seems to be a serious problem Why is this a serious problem? The weblogic docs for the flag you mention indicate the commit is still not done until the end of the transaction and that you would only notice this if your db allows for uncommitted reads. snip ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
Re: [JBoss-dev] ejbStore() delay seems to be a serious problem
David Esposito wrote: I am surprised that I am the only one that has raised this particular example. It seems like it's something that people would do every day. Actually it's far more common for people to complain about behavior closer to what you want - Why is ejbStore being called so often? when they access an entity directly from their client code. -danch Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
Re: [JBoss-dev] CVS update: jboss/src/etc class.java interface.java
Filip Hanik wrote: Sorry, it is a *very* clear need. And CVS just doesn't cut it. can't we, uhm you (I'm not a committer:), use some sort of tag which makes CVS automatically insert the comment and audit info into the actual code file? I know this is doable with CVS any thoughts? Doing that you mostly get revision comments like Changed a bunch of stuff: this should work now. Not quite what we had in mind. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss Linux startup scripts
What goes wrong, though? [EMAIL PROTECTED] wrote: Hello everybody, I found in the documentation a description on how to start and stop JBoss on a linux machine with an rc.d script. I made this on my machine, but JBoss is not starting up correctly (basically it is not starting at all). Does anybody have an idea, on how the startup script will work correctly? Mit freundlichen Gruessen / best regards Markus M. May Think4You AG Hanauer Landstrasse 135-137 60314 Frankfurt / Main T. +49 69 2424 18 14 F. +49 69 2424 18 60 mailto:[EMAIL PROTECTED] http://www.think4you.com ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS mysterious, at least for me...
Lennart Petersson wrote: Got the latest from branch 2.4 from CVS today and was looking for the newly implemented read-ahead stuff. I see that not all things regarding this are implemented in the 2.4 branch, some is in main branch. Look at src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCFindEntityCommand.java as an example where you can see that the latest contribution (findByPrimaryKey may now do a read-ahead depending on configuration by Bill Burke) is made on the main branch and not 2.4 branch. I'll move the code from HEAD to the 2.4 branch over the next couple of days. I need to transition my tests into JBossTest to do this. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS mysterious, at least for me...
Bill Burke wrote: danch, If you need any help, send me an email, since I'm responsible for this. I just thought that this was a new feature that I added and wouldn't be allowed into 2.4. I was a bit unsure of that, too, but this is pretty important. Also, given that Dain has committed a 2.0 CMP implementation based on but sharing no code with JAWS, we may want to move our efforts over there for RabbitHole. Also, I can share the test writing load if you like. I'm feeling a little guilty that I'm checkin in stuff that I'm not writing a JBoss-Test for, although I have tested the changes against our application's test framework. I already have generic test code for this - I just need to adapt it to use JUnit, and tighten it up a bit so that I can automate the process of telling whether it worked or not. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Can Home references get stale?
taking a _quick_ look into the java.rmi.dgc package it looks like Remote
references (which your Home references now are - Right?) can indeed get
stale. the DGC ackage works on a lease basis, where each lease has a
certain duration. Not that I know what to do about it at this point.
-danch
Bill Burke wrote:
We save a reference to our homes in a static variable in various classes
so that we don't have to keep looking it up.
--
class SomeClass
{
public static MyBeanHome myBeanHome = null;
public void init()
{
InitialContext ctx = new InitialContext();
myBeanHome = (MyBeanHome)ctx.lookup(MyBean);
}
}
--
Jetty/JBoss(2.2.1) has been running for a few days now and we're getting
the folloowing exception when we call a finder on SomeClass.myBeanHome
java.rmi.MarshalException: Invalid remote object
no stack trace available
If we don't use myBeanHome and instead use one freshly looked up in the
InitialContext, the finder works fine.
BTW, we have Optimized set to False in standardjboss.xml so all
parameters are RMIized. We've had our service running for more than a
few days before and never got this problem, we used to have Optimized
set to True. That's the only thing I can think that's different.
Thanks,
Bill
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
marc fleury wrote: as I said the simpler design is with nopassivation stuff in it. I believe with gig ram machines floating around you can carefully design your deployment so that you will never need passivation. That's true for 99% of possible installations, but there will always be databases that won't fit into memory. Also, if you run a single VM on a 1GB linux box and try to give it that big a heap and have the number of users that that size implies, i suspect you'll have some mighty big threading and garbage collection issues with the current Tomcat/RMI implementations. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
marc fleury wrote: I am about to commit an MBean / EJB pair whose only purpose in life is to stress the cache locking logic. Because it is an MBean it never goes through the RMI layers and so we are seeing RAW performance of the logic that does the thread mutex semaphore and all taht... that was the part I had to optimize when I went to SUN... now with the new logic 50 threads all pinging on 1 object. on my new athlon it crawls to an halt at 50 clients in parallel (they wait 100ms before pinging again) and there is almost no invocation going through... This is a good test because it shows worst case, but can it be called a realistic test? I'm only bringing this up because, well, if I saw somebody with an application designed such that every user had to share a single synchronized object, I'd say well, yah, that'll perform fer shite! :( anybody ELSE seen this? I am almost leaning towards TOTALLY removing the passivating caches and associated mutex logic as is It does look like the behavior people have been complaining about. I'd not be in favor of permanently removing the passivating caches, however - making them non-default, sure, rewrite them absolutely, but they really have to be available for truly large installations. Truly large installations (running over N terabyte databases) will still need memory management. No that's not a typical installation, but don't you want to be able to support it? Ok I will say the word... this is shite ... or is it just me? marcf _ Marc Fleury, Ph.D [EMAIL PROTECTED] _ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Dain Sundstrom wrote: |Will this affect commit Option A and B, which doesn't passivate? I'm not true. Even under option A if you are under heavy load, the cache can passivate under you. Good, I guessed from the code that passivation ment that we need to reload the data after activation (i.e., bean data should not be keept, in the vm, after a passivation). During passivation I de-referance the bean data. I'm just curious what was the passivation cache for? -dain Memory management. If your database contains 10 GB and you only have 1GB of memory, you'll need to swap out some bean based on some criteria (LRU by default) to make room. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] EJX and XML
Rickard Öberg wrote: yep, also for those that really want I believe the for pay add-on will be a killer... look who is still lurking :) hey kiddo, when you pull your head out of your arse and your coma, you can come and help us again, it is a shame to see so much talent go to waste... do you like what you hear on JB3.0? Well, the mgmt yadda yadda is nice 'n all, but the big problem is still there: it'll run piss-poor with Tomcat. It doesn't really matter what fancy stuff you can think up with that crap hanging around. There, I said it, it pisses me off. The J2EE stack is a dream but nothing more unless Tomcat is fixed. Which is why Jules has been busy getting Jetty working. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] EJX and XML
Rickard Öberg wrote: On Mon, 25 Jun 2001, Rickard Öberg wrote: AFAICT the only problem in integrating with Tomcat is the whole ClassLoader architecture. AFAIK no it isn't. That was nailed ages ago. Works great. Except that Jasper has different behavior when it compiles JSPs than when they're run. (the classes in ejb-jars in the ear are available at run time, but not when Jasper is compiling.) What doesn't work great is Tomcat. It's dead slow. Do some benchmarks and be disturbed. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Dain Sundstrom wrote: I'm just curious what was the passivation cache for? Memory management. If your database contains 10 GB and you only have 1GB of memory, you'll need to swap out some bean based on some criteria (LRU by default) to make room. -danch Exactly, so what was the passivation cache? During passivation we want to dump data to make room for new objects. I think I'm lost... Why would we want to cache objects that we are tring to remove from memory? -dain It's a cache that passivates when it has over a certain number of object within it. It doesn't passivate what it's trying to cache, it passivates the overage. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Dain Sundstrom wrote: So if we remove the passivation cache, do we loose commit Option A? If not, how do we keep bean data alive while passivated? I still may not understand this. I think Mark is just suggesting losing the passivation part of the cache. The cache we keep, it just keeps growing and growing and growing. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: The next generation GUI (was : Re: [JBoss-dev] EJX and XML)
Dain Sundstrom wrote: I was just picking a fight :) OK, I just discarded my rant-mail. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CMP 2.x Quick How-to
Maybe as a first question - how 'done' do you consider the basic architecture of the CMP2.0 module? Done enough that there aren't going to be any major structural changes, or might it get turned upside down? As a frame of reference for my frame of mind, in my statements/questions below, I'm assuming that it _won't_ get turned upside down. Dain Sundstrom wrote: The query-method element is right out of the EJB 2.0 spec. The declared-sql element is similar to jaws finder element, except I have broken the query element into from and where. Thank you. having them combined made some things really painful. This is something I was going to change in JAWS. I also support order as jaws did. The new code doesn't have the new pre-load logic, but I will add something similar in phase 3, where I'll add ejb-ql support. Do you have any objection to Bill or I getting the initial underpinnings in there now? It's changed quite a bit since the version of JAWS that you (apparently) based your new work on. On a related (triggering, in fact) note: do you see your CMP implementation obsoleting JAWS, or augmenting it? Personally, I had intended on taking a chainsaw through JAWS anyway, so I wouldn't mind seeing it obsoleted. If it's obsoleted, I really think we may as well get more people than you working on it - hence the above question. Or if not, I'll find something else to do. If you find any bugs or would like to request a feature, please email me. I will fix bugs as they are discovered, and feature req1uests I will definitely think over. I really think that these should be posted on the sourceforge site - bugs because it lets us get more bandwidth - people other than you can fix the bugs, which means that more eyes will be on the code, which will lead to better code. That's why it's open source, after all. thanks, danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
Dain Sundstrom wrote: I don't know if you wanted with user configurable, but for now it will allow you to play with different levels. I can make it static later. static? ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Fw: [JBoss-dev] Shouldn't expose transaction-isolation within CMP
Dain Sundstrom wrote: I think I understand now. Here is some text I found the J2EE tutorial: You cannot modify the isolation level of a entity beans with container-managed persistence. These beans use the default isolation level of the DBMS, which is usually READ_COMMITTED. I don't remember the spec saying that the container had to use the database default isolation level. Is this remark more about the RI than what containers in general should do, or did I miss something? Do not change the isolation level in the middle of a transaction. Usually, such a change causes the DBMS software to issue an implicit commit. D'Oh! I'd expected an exception in that case. --- So the code I added probably causes an implicit commit, which is bad. From my very JDBC centric perspective, this should be set in Minerva (JBossPool?) and user configurable. I don't know much about the connector architecture, so maybe Minerva is the wrong place. Any way, I think I should roll back my change. I'd agree. If you agree marc, just say so and it is done. But I'm not marc. I don't know any thing about Minerva, so if you want that changed, someone else would be better suited. If no one wants to do it, I'll look at it. -dain -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] High load...
David Jencks wrote: Read on - the problem with this occured to a few of us already. Although none of us mentioned putting it in the container-transaction - that's interesting. But what if a method at iso 'read-uncommitted' calls a method in an iso 'serializable' transaction? thanks, danch Hi, Forgive me if I am talking nonsense, but doesn't it only make sense to have transaction isolation per transaction I very much doubt you will find a db that can support several transaction isolation levels within one transaction. I can't quite figure out what it would mean, either. So I say, put it with the transaction requirements for methods - Requires, Requires New, etc. Then you can set the isolation each time you start a new transaction, based on this specification. david jencks On 2001.06.26 14:48:00 -0400 Dain Sundstrom wrote: |I added transaction isolation to the new cmp plugin. You can set it by |adding the transaction-isolation element after the datasource element. |Valid levels are: |transaction-none |transaction-read-committed |transaction-read-uncommitted |transaction-repeatable-read |transaction-serializable | |Give me 10 minutes and I'll add it to JAWS... ok but these will be leveraged by new caches in JBoss 3.0 so I would imagine that each application can set its own datasource isolation level, (different kinds of bean). So it IS user configurable right??? Also how does it play with the datasources, if the datasource is shared across applications and different tables support different locking policies (say one table is RO the other RW) can the driver support sequential setIsolationLevel that only applies to the record and or table touched? marcf Right now this the jaws and jbosscmp code only support datasource per application. When we implement datasource per bean, we can have isolation level per bean. This leads to the intresting situation with EJB-QL queries that thouch multiput beans. May be we need to specify an isolation lever for each query. Havn't thought about it much. Right now you can only set it for the entire ejb-jar. Just tell me when you get the cache stuff figgured out and I can update jaws and jbosscmp to support what ever you want. -dain ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Where is everyone today?
The first implementation of the read-ahead messed around with the caches before I decided that I didn't like it and took that out. -danch Dain Sundstrom wrote: Jay, Great point. Up until I started on this code, no part of JBossCMP worked with the other container objects (cache, invoker etc); JBossCMP was executed by the container via the persistence store interface. I'm going to have to think about this. Thanks for helping to clarify my bad feeling, -dain -Original Message- From: Jay Walters [mailto:[EMAIL PROTECTED]] Sent: Friday, June 29, 2001 2:01 PM To: '[EMAIL PROTECTED]' Subject: RE: [JBoss-dev] Where is everyone today? I would think you'd want to be out of the guts too, that just seems a bit too closely coupled with JBoss for the persistence manager. Shouldn't the CMP persistence manager be some type of layer on top (well almost on top) with a well defined interface? This should clearly tie in to take advantage of what the container can provide. I am definitely on the outside of JBoss though, so marc et al are the people to listen to. Cheers -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED]] Sent: Friday, June 29, 2001 2:53 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Where is everyone today? Yo Dain, I know absolutely nothing about CMP 2.x Relationships, but it makes me really worried that you are working directly with EntityEnterpriseContexts from the container.cache. Why aren't you going through the HOME interfaces to access related beans? Remember, each entity type can have entirely different datastores, caching mechanisms, locking mechanisms, synchronization mechanisms, and pooling mechanisms. You shouldn't really be circumventing how to access a bean. If I'm totally out of my league here, I'll just apologize and shut up. Let me know, but in the meantime, I'll try to review the CMP 2.x Relationships. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dain Sundstrom Sent: Friday, June 29, 2001 2:22 PM To: '[EMAIL PROTECTED]' Subject: [JBoss-dev] Where is everyone today? Is everyone on vacation? Is the list working? What-ever, doesn't really matter. If any one is around today, and can reply to my message, I would greatly appreciate it. I kind of need some guidance on the decision to create an interceptor or not. I'm going to continue along the line that I don't need an interceptor (I can always add it later). If you all are on vacation, have a great time. -dain -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 28, 2001 11:48 PM To: '[EMAIL PROTECTED]' Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation marc, Do you mean that I should be setting invoked, or something else? I got the bi-directional one-to-one (enforced integrity) working using the entity cache, but it gives me a bad feeling. In the this case, there may be up to 4 beans that need to be stored: before: a1--b1 a2--b2 a1.setB(b2) after: a1\ b1 a2 \b2 So, I hold onto up to three other contexts. When my store is called, I write my state and then store the other contexts (with their respective mangers). This won't cause extraneous writes as 'tuned updates' is always on. What is giving me the bad feeling is I have just cut out all of the work that is being done in the interceptors, specifically EntitySynchronizationInterceptor. For example, do I need to remove the context from the cache at the end of the transaction? Do I need to lock the context? What if one of the beans is removed? (the new remove procedure for relationships may handle this, but haven't implemented it yet) As you can tell this has given me a lot of concern. If this is stuff I shouldn't worry about, good. If I should worry, will it be better to create the new interceptor, thus reusing the code in the other interceptors, or will it be easier to handle the few special cases in the persistence store? -dain -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 28, 2001 9:53 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation also be sure to report right here is you touch any of the information in the ctx (using setters) marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Dain |Sundstrom |Sent: Thursday, June 28, 2001 9:45 PM |To: '[EMAIL PROTECTED]' |Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation | | | | The only way I can find to get a ctx for a pk | |is from EntityInstanceInterceptor, and the only way to get to the | |EntityInstanceInterceptor is container.invoke(mi). | | no no no it's in the cache, | | container.cache.get(id) (or something like that) | | marcf | | |YES! Thanks so much. I didn't want to write the interceptor. |This is going |to be way easier. I'm going to go code now. | |-dain
Re: [JBoss-dev] Where is everyone today?
Dain Sundstrom wrote: Bill, Thanks for the reply. I really need other people thinking about this, because I don't understand the rest of the container. Here's the deal. I delegate the actual storage of the other updated contexts to the their respective persistence storage managers, so they get stored by correct data source. I also get references to the other beans through their container's cache. Errr. I was nervous enough about the persistence manager messing with its own bean's cache, let along messing with other bean's caches. I think the biggest problem with this implementation is that my persistence store is directly calling store on other persistence stores, thus by passing all of the code that is supposed know the right way to do this. Ya, this makes me nervous too - there's too much that can go wrong. Really to get the store going you should be hooking into the transaction (which is the job of the EntitySynchronizationInterceptor) What about Bill's suggestion to go through the homes? That may not be the best performance, but then you know that all the Right Things are happening, even if (when) the definition of Right Thing changes. Short circuiting the interceptor chain is bad, IMHO. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-438115 ] JAWS lower-cases custom finder SQL text
Georg Rehfeld wrote: Hi danch, Does anybody know what databases are case sensitive WRT column and table names (or even keywords). I've never run into case sensitive SQL databases before. MySQL too is case sensitive on database, table and index names on a case sensitive file system (i.e. xNIX) with some table types especially the default MyISAM table type. The reason is, that they simply use the given name to generate a file path from it. Gak! Well, Vinay's fixed that bug already. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] remove transactional
I agree with Bill - removing everything involved in the rolled-back transaction from the cache is a must. -danch Bill Burke wrote: Nope, with the old code, B would be removed from the cache when b.remove() was called even if it was invoked from within a transaction. Also, all beans involved with a transaction would be removed from the cache on a rollback within InstanceSynchronization. I think that is the safe and correct approach to remove any bean from the cache that is part of a rollback. Otherwise you may have corrupted data. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Tuesday, July 03, 2001 2:57 PM To: Jboss-Development@Lists. Sourceforge. Net Subject: [JBoss-dev] remove transactional as I wrap up the stuff, sanity check bean a and bean b a starts transaction and calls b.remove() and then rolls back b is still there in cache right? marcf _ Marc Fleury, Ph.D [EMAIL PROTECTED] _ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jaws_2_4.dtd not valid
You can have only one definition of the datasource element - and that's all we need since it's the same either place (just contains CDATA). As long as it's listed as a possible contained element for both the global jaws element, and the entity-bean element, we should be fine. Unless I'm missing something. -danch Vinay Menon wrote: Mike, That is a bean level datasource and quite obviously cannot be commented out in principal! I mean if you got to have a bean level ds you got to have one! Client programs should be able to define a datasource at the file level i.e. applicable to all the beans declared in the jaws.xml and the datasource at the bean level essentially overrides it. Vinay - Original Message - From: Mike Swainston-Rainford [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 11, 2001 11:40 PM Subject: [JBoss-dev] jaws_2_4.dtd not valid the jaws dtd is no longer valid. The datasource element is defined twice. This mucks up any validating editor/parser (like XMLSpy) used to edit a jaws.xml file. Suggest the second definition at line 69 is a comment thus:- !-- The datasource at bean level. If specified the bean will use this datasource instead of the global one. Else the global one is used -- !--ELEMENT datasource (#PCDATA)-- Mike S-R ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
