Re: a question in EJB
Could you write in the kind of JARs added and also the exact error message you are getting? === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: A question
Hi, Can you please post what version of Weblogic are you using? I tried this with WLS 9.1 version and it works fine for both cluster and standalone server. Thanks === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: A question
It works neither in a cluster or in a standalone server. From: Saini, Deepak Sent: Thursday, March 16, 2006 2:37 PM To: Saini, Deepak Subject: A question Hi, The class CachingLocalHome in Weblogic provides methods to invalidate the read only entity bean instances. For some reason, it is not clearing these instances. Has any one faced this problem at any time or is aware of any issues related to entity bean caching in Weblogic? Regards Deepak Saini Accenture Communications High Tech. Bangalore, India Phone: +91 80 418 60326 This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: A question about primary key generation
We currently have a DAO class contained in a common utility jar within our EAR file. Up to this point most of our Databases access has occurred through the use of entity beans, but we're looking to move more to DAOs. Here is the problem: While using entity beans, we employed a PrimaryKeyGenerator entity bean during inserts. Of course, this is a HI-LO key generator, right? Now that we moved some of our database logic out of the entity beans and into this DAO class which is now outside of the EJB jar, how can we generate primary keys? It is my understanding that having code within a common jar that is included in the EAR make a call to EJB code is in violation of the J2EE paradigm. I disagree. The thing is, who calls the jar? Probably other EJBs, right? Then you can call. Alternatively, you could place all the key generation code inside your DAO, both key generation and database code, and use JDBC directly(it should be quite simple, usually HI-LO generators use a table with 2 or 3 fields) My 2c, JP === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: Newbie question: What is the benefit from Entity Beans?
Dave, The performance of Entity Beans was a cause of concern till EJB 1.1. The specification requried the container to load at the begining of every transaction and store at the end of it. Also there was no standard way of determining whether the entity bean state has changed or not. Some CMP containers had proprietry ways. With EJB 2.0 the requirements for loading and storing the the bean state is relaxed. Refer the extract below reproduced from the EJB 2.0 pecifications( pg 169 third bullet). When an entity bean instance is in the ready state, the instance is associated with a specific entity object identity. While the instance is in the ready state, the container can synchronize the state of the instance with the state of the entity in the underlying data source whenever it deter-mines the need to, in the process invoking the ejbLoad() and ejbStore() methods zero or more times. A business method can be invoked on the instance zero or more times. Invoca-tions of the ejbLoad() and ejbStore() methods can be arbitrarily mixed with invoca-tions of business methods. The abstract getter/setter methods help the Container to determine the whetner the bean is dirty thereby reducing the database trips even at the end of the transactions. Another important aspect is how the Transaction semantics are applied. Ideally all the setter method should be executing under the same transaction context. A good CMP engine in addition to this will provide efficient caching. Hope that this answers your doubts on Entity Bean's performce. AK. - Original Message - From: Dave Glasser [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 11, 2002 11:39 PM Subject: Re: Newbie question: What is the benefit from Entity Beans? On Sun, 8 Sep 2002 19:29:58 +0200, Kriss [EMAIL PROTECTED] wrote: Hi all, after having read some books and articles about ejb, I am wondering what´s the benefit from [BMP] Entity Beans and what would one loose if completely leaving them out. I asked this same question here a while back and got some interesting replies. The thread can be seen here: http://swjscmail1.java.sun.com/cgi-bin/wa?A2=ind0101L=ejb-interestP=R33708 My opinion on entity beans is that they were a lousy idea, from both an architectural and a performance standpoint. I have no direct experience with CMP, but from what I've seen, I doubt that it's used successfully for many large-scale projects--there's always going to be some kind of custom business rules that need to be applied when an object is saved, etc. For my first big J2EE project (when I first posted the question about entity beans you're asking now) we decided to avoid them entirely. On my second one (which wasn't as big as the first) we had to integrate with an existing system that was using them, and it wasn't bad because we only had to call a few that were already written, and the system wasn't high-volume enough that the entity beans created a bottleneck. The project I'm on now, which is fairly large-scale and which I joined sort of in the middle, uses them everywhere, for practically every database read and write in the system. When I see how heavily the database gets hammered for the simplest things, well, let's just say I have concerns about how well the system will scale once it's deployed. Let's say you have a Customer entity bean, and for a particular customer you want to change the first and last name. Here's what happens, at least in Websphere running within WSAD: 1. Assuming you have the home interface already, call findByPrimaryKey with the customer's PK. * Within ejbFindByPrimaryKey, you use the pk fields to select the pk fields from the customer table. Or you can do a select count(*), to simply verify that it's a valid pk. * The container will then call ejbLoad(), where you read all of the data (hit number 2 on the database) and populate the bean's fields. A remote reference to the bean (the remote interface) is returned to the caller. 2. The application then calls setFirstName(String) on the Customer entity bean. * Even though the bean's fields are already populated, Websphere decides to play it safe and call ejbLoad() again, incurring the third database hit. * The container forwards setFirstName() call to your bean class, where the field get's changed. Then ejbStore() gets called to update the row for that customer. (But keep in mind that only the first name gets changed this time. 3. The application then calls setLastName(String), and the ejbLoad()/ ejbStore() cycle described in step 2. is repeated, for database hits 5 and 6. So here you've incurred 6 database hits (two of which were updates) to accomplish this: UPDATE customer SET first_name = 'Bob', last_name = 'Smith' WHERE customer_id = 12345. Multiply that by a thousand users and draw your own conclusions. Now before anyone chimes in about bulk accessor methods to update multiple fields
Re: Newbie question: What is the benefit from Entity Beans?
On Sun, 8 Sep 2002 19:29:58 +0200, Kriss [EMAIL PROTECTED] wrote: Hi all, after having read some books and articles about ejb, I am wondering what´s the benefit from [BMP] Entity Beans and what would one loose if completely leaving them out. I asked this same question here a while back and got some interesting replies. The thread can be seen here: http://swjscmail1.java.sun.com/cgi-bin/wa?A2=ind0101L=ejb-interestP=R33708 My opinion on entity beans is that they were a lousy idea, from both an architectural and a performance standpoint. I have no direct experience with CMP, but from what I've seen, I doubt that it's used successfully for many large-scale projects--there's always going to be some kind of custom business rules that need to be applied when an object is saved, etc. For my first big J2EE project (when I first posted the question about entity beans you're asking now) we decided to avoid them entirely. On my second one (which wasn't as big as the first) we had to integrate with an existing system that was using them, and it wasn't bad because we only had to call a few that were already written, and the system wasn't high-volume enough that the entity beans created a bottleneck. The project I'm on now, which is fairly large-scale and which I joined sort of in the middle, uses them everywhere, for practically every database read and write in the system. When I see how heavily the database gets hammered for the simplest things, well, let's just say I have concerns about how well the system will scale once it's deployed. Let's say you have a Customer entity bean, and for a particular customer you want to change the first and last name. Here's what happens, at least in Websphere running within WSAD: 1. Assuming you have the home interface already, call findByPrimaryKey with the customer's PK. * Within ejbFindByPrimaryKey, you use the pk fields to select the pk fields from the customer table. Or you can do a select count(*), to simply verify that it's a valid pk. * The container will then call ejbLoad(), where you read all of the data (hit number 2 on the database) and populate the bean's fields. A remote reference to the bean (the remote interface) is returned to the caller. 2. The application then calls setFirstName(String) on the Customer entity bean. * Even though the bean's fields are already populated, Websphere decides to play it safe and call ejbLoad() again, incurring the third database hit. * The container forwards setFirstName() call to your bean class, where the field get's changed. Then ejbStore() gets called to update the row for that customer. (But keep in mind that only the first name gets changed this time. 3. The application then calls setLastName(String), and the ejbLoad()/ ejbStore() cycle described in step 2. is repeated, for database hits 5 and 6. So here you've incurred 6 database hits (two of which were updates) to accomplish this: UPDATE customer SET first_name = 'Bob', last_name = 'Smith' WHERE customer_id = 12345. Multiply that by a thousand users and draw your own conclusions. Now before anyone chimes in about bulk accessor methods to update multiple fields with a single call, and clean/dirty flags to save unneeded updates in the ejbStore() method, I already know about them. But I have little patience for a design that requires me to go through so many gyrations to prevent it from being a total dog performance-wise. Heck, Websphere/WSAD even calls ejbStore() after a getter method, which doesn't even change the bean, is called! (To be fair, though, it has no way of knowing whether the bean has been changed or not.) Consider a scenario where you want to cancel all of the items on a customer's order, and this involves setting the STAT field of the ORDER_ITEM table to C for each cancelled item. Let's say instead of doing this: UPDATE order_item SET stat = 'C' WHERE order_num = 12345; A design document has been handed to you dictating that it must be done through entity beans. Here is what would happen: ejbFindByOrderNum() SELECT order_num, item_num FROM order_item WHERE order_num = 12345; // Return an Enumeration of OrderItemPK objects for each row in // the resultset. ejbLoad() SELECT * FROM order_item WHERE order_num = 12345; // this select will be executed once for each item on the order, // IOW 10 items = 10 selects. ejbStore() UPDATE order_item SET ... etc. // this will be executed once for each item on the order also. And then don't forget the overhead the container incurs for managing the lifecycle of all of your short-lived OrderItem beans. Of course, somebody might argue that you need coarser granularity, and you should just have an Order entity with a cancelAllItems() method on it. They would be right, too, but the more you move toward things that make sense, the farther you're moving away from the basic entity bean model, so what's the point of
Re: Newbie question: What is the benefit from Entity Beans?
All inline Juan Pablo Lorandi Chief Software Architect Code Foundry Ltd. [EMAIL PROTECTED] Barberstown, Straffan, Co. Kildare, Ireland. Tel: +353-1-6012050 Fax: +353-1-6012051 Mobile: +353-86-2157900 www.codefoundry.com -Original Message- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]] On Behalf Of Dave Glasser Sent: Thursday, September 12, 2002 4:39 AM To: [EMAIL PROTECTED] Subject: Re: Newbie question: What is the benefit from Entity Beans? On Sun, 8 Sep 2002 19:29:58 +0200, Kriss [EMAIL PROTECTED] wrote: Hi all, after having read some books and articles about ejb, I am wondering what´s the benefit from [BMP] Entity Beans and what would one loose if completely leaving them out. I asked this same question here a while back and got some interesting replies. The thread can be seen here: http://swjscmail1.java.sun.com/cgi-bin/wa?A2=ind0101L=ejb-int erestP=R33708 My opinion on entity beans is that they were a lousy idea, from both an architectural and a performance standpoint. A bold remark... I have no direct experience with CMP, but from what I've seen, I doubt that it's used successfully for many large-scale projects--there's always going to be some kind of custom business rules that need to be applied when an object is saved, etc. I see this a lot... People first make a bold remark, then issue a disclaimer ;-). I have used CMP in large scale projects. It works. Optimizations were needed in a few, very distinguishable spots. The rest of the performance problems were due to using the wrong architecture, which was fixed by refactoring and dumping parts and code from scratch; since CMP was used, it didn't consume large amounts of time. For my first big J2EE project (when I first posted the question about entity beans you're asking now) we decided to avoid them entirely. On my second one (which wasn't as big as the first) we had to integrate with an existing system that was using them, and it wasn't bad because we only had to call a few that were already written, and the system wasn't high-volume enough that the entity beans created a bottleneck. The project I'm on now, which is fairly large-scale and which I joined sort of in the middle, uses them everywhere, for practically every database read and write in the system. When I see how heavily the database gets hammered for the simplest things, well, let's just say I have concerns about how well the system will scale once it's deployed. Are entity beans to blame here or poor architecture? I know a lot of non-J2EE systems that hammer the database as well. Also some EJB containers have strict implementations that do not help much. Let's say you have a Customer entity bean, and for a particular customer you want to change the first and last name. Here's what happens, at least in Websphere running within WSAD: 1. Assuming you have the home interface already, call findByPrimaryKey with the customer's PK. * Within ejbFindByPrimaryKey, you use the pk fields to select the pk fields from the customer table. Or you can do a select count(*), to simply verify that it's a valid pk. * The container will then call ejbLoad(), where you read all of the data (hit number 2 on the database) and populate the bean's fields. A remote reference to the bean (the remote interface) is returned to the caller. 2. The application then calls setFirstName(String) on the Customer entity bean. * Even though the bean's fields are already populated, Websphere decides to play it safe and call ejbLoad() again, incurring the third database hit. * The container forwards setFirstName() call to your bean class, where the field get's changed. Then ejbStore() gets called to update the row for that customer. (But keep in mind that only the first name gets changed this time. 3. The application then calls setLastName(String), and the ejbLoad()/ ejbStore() cycle described in step 2. is repeated, for database hits 5 and 6. That's just Websphere in a very strong database integrity mode. I've used other servers and they implement the contract more eficiently. Orion(OC4J) has an exclusive-write-access mode in which there is only ONE read op. and a WRITE op. every N seconds. So here you've incurred 6 database hits (two of which were updates) to accomplish this: UPDATE customer SET first_name = 'Bob', last_name = 'Smith' WHERE customer_id = 12345. Multiply that by a thousand users and draw your own conclusions. OK. 6 x 1000 = 6000. 1 x 1000 = 1000. Thus you have something that performs 6 times worse than hand coding everything(let's ommit the fact that updates are much more heavy than simple select statements). It's still within the same order of magnitude. Also bear in mind that the simple UPDATE statement is optimistic locking of the database. It's
Re: ejbRemove question for StatelessSession bean
that is not an option - I gues my question can be generalised like this - if a stateless session bean takes resource like a db connection or jms session/producers - then how does it make sure it can close it? Taking the resource locally and using it and then closing it in a finally block is not going to help me. TIA Anamitra --- Matthias Bohlen [EMAIL PROTECTED] wrote: Hi, Anamitra, mark the bean as stateful. Cheers... Matthias -Original Message- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]] On Behalf Of Anamitra Bhattacharyya Sent: Monday, August 12, 2002 2:09 AM To: [EMAIL PROTECTED] Subject: ejbRemove question for StatelessSession bean Hi All It seems the ejbRemove method does not get called in case of SystemException being thrown from a stateless session bean. The container just destroys the bean. So how do I code to clear up the open resources like say a JMS session in case of a system exception? I create the session and store it in global variable when one of my remote methods get invoked. I understand that stateless session bean are not supposed to keep global variables - but in this case I am just hoping that all the instances of the bean created by the container will finally have their own session instances - that heps performance rather than creating the session on every invocation. But in case a system exception happens the bean instance gets remove I want to close the session - otherwise it results in a memory leak. Any help is appreciated. thanks Anamitra __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: ejbRemove question for StatelessSession bean
In a SLSB, unless you take the resource locally, it won't correctly enroll in the current transaction. I wonder if using a regular java class instead of a SLSB is possible? If the SLSB isn't transactional, stick to a regular java class. My 2c, Juan Pablo Lorandi Chief Software Architect Code Foundry Ltd. [EMAIL PROTECTED] Barberstown, Straffan, Co. Kildare, Ireland. Tel: +353-1-6012050 Fax: +353-1-6012051 Mobile: +353-86-2157900 www.codefoundry.com -Original Message- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]] On Behalf Of Anamitra Bhattacharyya Sent: Monday, August 12, 2002 2:31 PM To: [EMAIL PROTECTED] Subject: Re: ejbRemove question for StatelessSession bean that is not an option - I gues my question can be generalised like this - if a stateless session bean takes resource like a db connection or jms session/producers - then how does it make sure it can close it? Taking the resource locally and using it and then closing it in a finally block is not going to help me. TIA Anamitra --- Matthias Bohlen [EMAIL PROTECTED] wrote: Hi, Anamitra, mark the bean as stateful. Cheers... Matthias -Original Message- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]] On Behalf Of Anamitra Bhattacharyya Sent: Monday, August 12, 2002 2:09 AM To: [EMAIL PROTECTED] Subject: ejbRemove question for StatelessSession bean Hi All It seems the ejbRemove method does not get called in case of SystemException being thrown from a stateless session bean. The container just destroys the bean. So how do I code to clear up the open resources like say a JMS session in case of a system exception? I create the session and store it in global variable when one of my remote methods get invoked. I understand that stateless session bean are not supposed to keep global variables - but in this case I am just hoping that all the instances of the bean created by the container will finally have their own session instances - that heps performance rather than creating the session on every invocation. But in case a system exception happens the bean instance gets remove I want to close the session - otherwise it results in a memory leak. Any help is appreciated. thanks Anamitra __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com == == === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com == = To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: ejbRemove question for StatelessSession bean
Anamitra, According to the 2.0 spec, the only state transition from the method ready pool to does not exist state requires that the ejbRemove method be called. So your ejb container does not comply with the spec. Section 7.8.3 explicitly states that exceptions result in the transition to the does not exist state. --Victor === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: ejbRemove question for StatelessSession bean
Of course, Chapter 18 contradicts this by saying that the container must not call any call back methods when discarding an instance due to an system exception. However, section 18.3.7 states that all resources obtained from resource factories declared in the bean environment must be released. Maybe that will help. Otherwise, you'll have to catch all runtime exceptions and releaes your resources before rethrowing. --Victor Victor Langelo wrote: Anamitra, According to the 2.0 spec, the only state transition from the method ready pool to does not exist state requires that the ejbRemove method be called. So your ejb container does not comply with the spec. Section 7.8.3 explicitly states that exceptions result in the transition to the does not exist state. --Victor === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: ejbRemove question for StatelessSession bean
Hi Victor thats a good point - So it seems that only those resourses obtained from the resource factories declared in the bean env will be released by the container. But unfortunately mine is not - so I guess I will have to think of another solution. thanks Anamitra --- Victor Langelo [EMAIL PROTECTED] wrote: Of course, Chapter 18 contradicts this by saying that the container must not call any call back methods when discarding an instance due to an system exception. However, section 18.3.7 states that all resources obtained from resource factories declared in the bean environment must be released. Maybe that will help. Otherwise, you'll have to catch all runtime exceptions and releaes your resources before rethrowing. --Victor Victor Langelo wrote: Anamitra, According to the 2.0 spec, the only state transition from the method ready pool to does not exist state requires that the ejbRemove method be called. So your ejb container does not comply with the spec. Section 7.8.3 explicitly states that exceptions result in the transition to the does not exist state. --Victor === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: ejbRemove question for StatelessSession bean
Title: Re: ejbRemove question for StatelessSession bean What about using the finalize() method ? Benjamin Anamitra Bhattacharyya a écrit : Hi Victor thats a good point - So it seems that only those resourses obtained from the resource factories declared in the bean env will be released by the container. But unfortunately mine is not - so I guess I will have to think of another solution. thanks Anamitra --- Victor Langelo [EMAIL PROTECTED] wrote: Of course, Chapter 18 contradicts this by saying that the container must not call any call back methods when discarding an instance due to an system exception. However, section 18.3.7 states that all resources obtained from resource factories declared in the bean environment must be released. Maybe that will help. Otherwise, you'll have to catch all runtime exceptions and releaes your resources before rethrowing. --Victor Victor Langelo wrote: Anamitra, According to the 2.0 spec, the only state transition from the method ready pool to does not exist state requires that the ejbRemove method be called. So your ejb container does not comply with the spec. Section 7.8.3 explicitly states that exceptions result in the transition to the does not exist state. --Victor === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: ejbRemove question for StatelessSession bean
yeah - maybe I should consider that - or maybe create my own pool of sessions. thanks Anamitra --- Benjamin BONNET [EMAIL PROTECTED] wrote: What about using the finalize() method ? Benjamin Anamitra Bhattacharyya a écrit : Hi Victor thats a good point - So it seems that only those resourses obtained from the resource factories declared in the bean env will be released by the container. But unfortunately mine is not - so I guess I will have to think of another solution. thanks Anamitra --- Victor Langelo [EMAIL PROTECTED] wrote: Of course, Chapter 18 contradicts this by saying that the container must not call any call back methods when discarding an instance due to an system exception. However, section 18.3.7 states that all resources obtained from resource factories declared in the bean environment must be released. Maybe that will help. Otherwise, you'll have to catch all runtime exceptions and releaes your resources before rethrowing. --Victor Victor Langelo wrote: Anamitra, According to the 2.0 spec, the only state transition from the method ready pool to does not exist state requires that the ejbRemove method be called. So your ejb container does not comply with the spec. Section 7.8.3 explicitly states that exceptions result in the transition to the does not exist state. --Victor === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: ejbRemove question for StatelessSession bean
Hi Anamitra, Thanks for bring up this problem, which has bothered me too. Not only with SLSB's but with all type of enterprise beans, because a system exception from an enterprise bean will always make the container discard the bean without calling ejbRemove or another callback method. My best solution was to catch system exceptions and release resources before rethrowing, as Victor suggests. But in case of 'timeout' of a SFSB, the bean is also discarded, without calling ejbRemove - and I see no way of solving that. I wonder why SUN have chosen, that ejbRemove or unsetEntityContext is not called in those situations ?? kind regards Hardy On Monday 12 August 2002 09:44 pm, Anamitra Bhattacharyya wrote: yeah - maybe I should consider that - or maybe create my own pool of sessions. thanks Anamitra --- Benjamin BONNET [EMAIL PROTECTED] wrote: What about using the finalize() method ? Benjamin Anamitra Bhattacharyya a écrit : Hi Victor thats a good point - So it seems that only those resourses obtained from the resource factories declared in the bean env will be released by the container. But unfortunately mine is not - so I guess I will have to think of another solution. thanks Anamitra --- Victor Langelo [EMAIL PROTECTED] wrote: Of course, Chapter 18 contradicts this by saying that the container must not call any call back methods when discarding an instance due to an system exception. However, section 18.3.7 states that all resources obtained from resource factories declared in the bean environment must be released. Maybe that will help. Otherwise, you'll have to catch all runtime exceptions and releaes your resources before rethrowing. --Victor Victor Langelo wrote: Anamitra, According to the 2.0 spec, the only state transition from the method ready pool to does not exist state requires that the ejbRemove method be called. So your ejb container does not comply with the spec. Section 7.8.3 explicitly states that exceptions result in the transition to the does not exist state. --Victor === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. -- Hardy Henneberg Konsulentfirmaet HHenneberg Grønnevej 44 2830 Virum Danmark tel: (45) 26124565 http://www.hhenne.dk === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: ejbRemove question for StatelessSession bean
I completely agree with you - and SUN should do something to revise their spec for this. Whats the pupose of an ejbRemove if I still have to have finalize blocks or have to catch RuntimeExceptions in an EJB framework? Anamitra --- Hardy Henneberg [EMAIL PROTECTED] wrote: Hi Anamitra, Thanks for bring up this problem, which has bothered me too. Not only with SLSB's but with all type of enterprise beans, because a system exception from an enterprise bean will always make the container discard the bean without calling ejbRemove or another callback method. My best solution was to catch system exceptions and release resources before rethrowing, as Victor suggests. But in case of 'timeout' of a SFSB, the bean is also discarded, without calling ejbRemove - and I see no way of solving that. I wonder why SUN have chosen, that ejbRemove or unsetEntityContext is not called in those situations ?? kind regards Hardy On Monday 12 August 2002 09:44 pm, Anamitra Bhattacharyya wrote: yeah - maybe I should consider that - or maybe create my own pool of sessions. thanks Anamitra --- Benjamin BONNET [EMAIL PROTECTED] wrote: What about using the finalize() method ? Benjamin Anamitra Bhattacharyya a écrit : Hi Victor thats a good point - So it seems that only those resourses obtained from the resource factories declared in the bean env will be released by the container. But unfortunately mine is not - so I guess I will have to think of another solution. thanks Anamitra --- Victor Langelo [EMAIL PROTECTED] wrote: Of course, Chapter 18 contradicts this by saying that the container must not call any call back methods when discarding an instance due to an system exception. However, section 18.3.7 states that all resources obtained from resource factories declared in the bean environment must be released. Maybe that will help. Otherwise, you'll have to catch all runtime exceptions and releaes your resources before rethrowing. --Victor Victor Langelo wrote: Anamitra, According to the 2.0 spec, the only state transition from the method ready pool to does not exist state requires that the ejbRemove method be called. So your ejb container does not comply with the spec. Section 7.8.3 explicitly states that exceptions result in the transition to the does not exist state. --Victor === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. -- Hardy Henneberg Konsulentfirmaet HHenneberg Grønnevej 44 2830 Virum Danmark tel: (45) 26124565 http://www.hhenne.dk === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message === message truncated === __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general
Re: Transaction Question
1. If the single method call involves multiple transactions
then instead of using multiple transactions in a single method call,
it is better to break the method into multiple methods,
with each of the multiple methods having its own container-managed
transaction.
Use 2 session beans: bean A and bean B.
The client calls Bean A, which has transaction attribute NOT_SUPPORTED, so that bean
A doesn't start a transaction. Then Bean A calls each of the three methods on bean B,
with those methods set with transaction attribute REQUIRED. Since Bean A won't
start a transaction, each call to a method of bean B will start and commit their own
transactions.
//Psuedo code... (I'm leaving out the home.create steps for brevity)
public class BeanA implements javax.ejb.SessionBean {
//Use TX Attribute NOT_SUPPORTED
public void foo() {
beanB.method1();
beanB.method2();
beanB.method3();
}
}
public class BeanB implmenets javax.ejb.EntityBean {
//Use TX Attribute REQUIRED for each of these methods
public void method1() {...}
public void method2() {...}
public void method3() {...}
}
2. You define a single transaction that spans multiple EJB method calls.
For example, you define a stateful session EJB that uses one method to
begin a transaction, and another method to commit or roll back a
transaction
To have 1 transaction span both all 3 calls to bean B, simply change bean A's
transaction attribute to REQUIRED. Now Bean A starts the transaction and each
method in Bean B will participate in Bean A's transaction.
//Psuedo code... (I'm leaving out the home.create steps for brevity)
public class BeanA implements javax.ejb.SessionBean {
//Use TX Attribute REQUIRED to have all of foo() be in 1 transaction
public void foo() {
beanB.method1();
beanB.method2();
beanB.method3();
}
}
public class BeanB implmenets javax.ejb.EntityBean {
//Use TX Attribute REQUIRED for each of these methods
public void method1() {...}
public void method2() {...}
public void method3() {...}
}
How can we use the Bean Managed Transactions or the container managed
transactions in above scenarios..
I hope the above helps. Container transactions are much easier to work with then bean
managed transactions. To learn more about managing transaction boundaries, you should
get a good EJB Book or opt for a good EJB training class.
Doug Bateman
Sr. Enterprise Java Architect and EJB Instructor
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff EJB-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
Re: corected question on ejbActivate()
Amit, You should never invoke Container callback methods from your bean code. If your AppServer supports the Transaction Commit Option C (we do :), then beans in the transactional state (where business methods are executed) will return to the pool at the end of the transaction. For beans to move into the transactional state again from the pool [in Option C], the Container will have to invoke the ejbActivate(), followed by other Container callback methods. ejbActivate() only associates an instance with its primary key - in other words, an identity. And on a similar vein, the ejbPassivate() disassociates an instance with its identity (that is, goes back back to the pool). Note that transaction commit option C is slower than B when your application exhibits locality of reference. -krish -Original Message- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Amit Kumar Sent: Friday, August 02, 2002 11:29 AM To: [EMAIL PROTECTED] Subject: corected question on ejbActivate() my previous mail contain some typos here is the correct mail In an Entity Bean corresponding to ejbActivate() method please correct me if my understanding is not correct: A bean after creation goes to pool. If some client calls create then a bean is picked up from the pool and then its ejbCreate() followed by ejbPostCreate() is called. Now if come business mehtod is invokded it will be executed. In this way ejbActivate() doesnot get a chance be executed ,so if I want to ensure that the ejbActivate() must have been called before any business method execution I must call ejbActivate() from the ejbPostCreate(). Best regards Amit K === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: corected question on ejbActivate()
Amit, The ejbActivate() is not called when the ejbCreate() is called. I'd suggest you refer to the EJB spec (either 1.1 or 2.0) which enumerates the life-cycle of entity beans in some detail. I could send across a document that enumerates the behavior of entity beans when running under Borland Enterprise Server if you're interested. This should hopefully give you some idea, but you need to check up on how things work with your vendor. On a related note, I do not see why you seem to want to trigger the ejbActivate() of an entity bean - which is a Container callback method and not a method triggered programmatically by a bean developer. -krish -Original Message- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Amit Kumar Sent: Friday, August 02, 2002 3:46 PM To: [EMAIL PROTECTED] Subject: Re: corected question on ejbActivate() Thank you Krish for the prompt reply but does this mean ejbPostCreate() is always followed by ejbActivate() because after all a client can call business method on a bean with identity only (I am talking about the business methods in the remote interface. Amit, You should never invoke Container callback methods from your bean code. If your AppServer supports the Transaction Commit Option C (we do :), then beans in the transactional state (where business methods are executed) will return to the pool at the end of the transaction. For beans to move into the transactional state again from the pool [in Option C], the Container will have to invoke the ejbActivate(), followed by other Container callback methods. ejbActivate() only associates an instance with its primary key - in other words, an identity. And on a similar vein, the ejbPassivate() disassociates an instance with its identity (that is, goes back back to the pool). Note that transaction commit option C is slower than B when your application exhibits locality of reference. -krish -Original Message- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Amit Kumar Sent: Friday, August 02, 2002 11:29 AM To: [EMAIL PROTECTED] Subject: corected question on ejbActivate() my previous mail contain some typos here is the correct mail In an Entity Bean corresponding to ejbActivate() method please correct me if my understanding is not correct: A bean after creation goes to pool. If some client calls create then a bean is picked up from the pool and then its ejbCreate() followed by ejbPostCreate() is called. Now if come business mehtod is invokded it will be executed. In this way ejbActivate() doesnot get a chance be executed ,so if I want to ensure that the ejbActivate() must have been called before any business method execution I must call ejbActivate() from the ejbPostCreate(). Best regards Amit K === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: corected question on ejbActivate()
Amit, perhaps I might have a go at explaining it from a different viewpoint than others in ejbActivate you basically do lookups of any _instance_specific_things_ (as opposed to non-instance specific lookups that should occur in setEntityContext). The reason this method isn't called in the create cycle is that those instance specific things would be looked up as part of the create method. hth cheers dim - Original Message - From: Krishnan Subramanian [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, August 03, 2002 12:43 AM Subject: Re: corected question on ejbActivate() Amit, The ejbActivate() is not called when the ejbCreate() is called. I'd suggest you refer to the EJB spec (either 1.1 or 2.0) which enumerates the life-cycle of entity beans in some detail. I could send across a document that enumerates the behavior of entity beans when running under Borland Enterprise Server if you're interested. This should hopefully give you some idea, but you need to check up on how things work with your vendor. On a related note, I do not see why you seem to want to trigger the ejbActivate() of an entity bean - which is a Container callback method and not a method triggered programmatically by a bean developer. -krish -Original Message- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Amit Kumar Sent: Friday, August 02, 2002 3:46 PM To: [EMAIL PROTECTED] Subject: Re: corected question on ejbActivate() Thank you Krish for the prompt reply but does this mean ejbPostCreate() is always followed by ejbActivate() because after all a client can call business method on a bean with identity only (I am talking about the business methods in the remote interface. Amit, You should never invoke Container callback methods from your bean code. If your AppServer supports the Transaction Commit Option C (we do :), then beans in the transactional state (where business methods are executed) will return to the pool at the end of the transaction. For beans to move into the transactional state again from the pool [in Option C], the Container will have to invoke the ejbActivate(), followed by other Container callback methods. ejbActivate() only associates an instance with its primary key - in other words, an identity. And on a similar vein, the ejbPassivate() disassociates an instance with its identity (that is, goes back back to the pool). Note that transaction commit option C is slower than B when your application exhibits locality of reference. -krish -Original Message- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Amit Kumar Sent: Friday, August 02, 2002 11:29 AM To: [EMAIL PROTECTED] Subject: corected question on ejbActivate() my previous mail contain some typos here is the correct mail In an Entity Bean corresponding to ejbActivate() method please correct me if my understanding is not correct: A bean after creation goes to pool. If some client calls create then a bean is picked up from the pool and then its ejbCreate() followed by ejbPostCreate() is called. Now if come business mehtod is invokded it will be executed. In this way ejbActivate() doesnot get a chance be executed ,so if I want to ensure that the ejbActivate() must have been called before any business method execution I must call ejbActivate() from the ejbPostCreate(). Best regards Amit K === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: CMP question
For one thing when you use the session facade you can use a local interface for the entity. Also your session bean can act as a controller for subsequent calls to other entity beans. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: serializable question
Possibly a CLASSPATH problem, where you have an older class of Business that did not
implement Serializable, which WL Classloader is picking up instead of the new one.
Try deleting all your classes, recompile, check the CLASSPATH of WL startup, and even
put
debug code in your SLSB (if(!(business instanceof Serializable) ...)
Gene
--- Joel Thompson [EMAIL PROTECTED] wrote:
Hi,
I am using Weblogic 5.1 on NT and am getting a
UnmarshalException, followed by a InvalidClassException
stating that my class is not serializable.
I am trying to return an ArrayList of Business objects
with a call to a Stateless Session Bean.
Here is a sampled Business class definition:
// Business Remote Interface
package rhino;
public class Business implements java.io.Serializable
{
private String m_sBusinessName=;
private String m_sID=;
private String m_sPhone=;
public Business(String p_sID, String p_sName,String p_sPhone)
{
m_sBusinessName=new String(p_sName);
m_sID=new String(p_sID);
m_sPhone=new String(p_sPhone);
}
public String getBusinessName(){return new String(m_sBusinessName);}
public String getID(){return new String(m_sID);}
public String getPhone(){return new String(m_sPhone);}
}
And here is a sampled SLSB function:
public ArrayList getBusiness(String p_sBusinessName) throws RemoteException
{
ArrayList al=new ArrayList(10);
al.add(new Business(10,Big 10, 530-111-2221));
al.add(new Business(11,Big 11, 530-111-));
al.add(new Business(12,Big 12, 530-111-2223));
al.add(new Business(13,Big 13, 530-111-2224));
return al;
}
On the client APP I am doing:
ArrayList al=qb.getBusiness(Big);
System.err.println(calling al.iterator());
Iterator itr=al.iterator();
Business biz=null;
System.err.println(calling itr.hasNext());
while(itr.hasNext())
{
System.err.println(next());
biz=(Business)itr.next();
System.out.println(found: + biz.getBusinessName()
+ biz.getID()
+ biz.getPhone());
}
The error I get is:
weblogic.rmi.UnmarshalException: Unmarshalling return
- with nested exception:
[java.io.InvalidClassException: rhino.Business; is not Serializable]
Can someone help in identifying the problem?
Thanks,
Joel
--
RHINO Systems Inc.
Consulting For Your Business
Project Manager
Programmer {JAVA J2EE,ORACLE,HTML JAVASCRIPT,
UNIX,C/C++, ESRI-GIS, SMART CARDS}
http://www.rhinosystemsinc.com
530-888-6248 x205
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff EJB-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
__
Do You Yahoo!?
Yahoo! Sports - sign up for Fantasy Baseball
http://sports.yahoo.com
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff EJB-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
Re: Transaction question...
1 --- It depends upon trans-attribute of entity bean B, if it is required or supported, EJB will execute entity bean B in same transaction of entity bean A 2 --- Assuming entity bean B is not executing in same transaction context of entity bean B, it will not affect the transaction of entity bean A. This is because EJB 2.0 does not support nested transactions, it support only flat. Thanks -- Vikram -Original Message- From: Nanik Tolaram [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 19, 2002 4:39 PM To: [EMAIL PROTECTED] Subject: Transaction question... Hi Friends, I have a question to ask about transaction. Here is the scenario... Client -- Servlet -- Entity Bean A (Container Managed Transaction and Container Managed Persistence) -- Bean B (Bean Managed Transaction and Bean Managed Persistence) I read in the spec EJB 2.0 section 17.6.1 it says .. the Container suspends any transaction that may be associated with the client .. (this would happen if the instance..), the container associates the method execution with this transaction correct me if I'm wrong please, does this mean that, 1. When Entity Bean A invoke the method on Entity Bean B the transaction that is currently attached to Entity Bean A is suspended and then it will resume the transaction again after it return back from Entity Bean B ? 2. Does the transaction in Entity Bean B affect the transaction in Entity Bean A ?, what I'm trying to say is if Entity Bean B rolled back for some reason does this roll back the transaction in Entity Bean A ? Thanks for the help and have a nice day Cheers Nanik _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: Transaction question...
Hi Vikram, Thanks for the reply, but as you the transaction in Entity Bean B is Bean Managed Transaction and not Container Managed Transaction, as you mention that it all depends on the trans-attribute of the bean, which I assume is the trans-attribute in the deployment descriptor which in Entity Bean B there is none as it is a Bean Managed Transaction Correct me if I'm wrong. Thanks Nanik From: Vikrama Ditya [EMAIL PROTECTED] Reply-To: Vikrama Ditya [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Transaction question... Date: Tue, 19 Feb 2002 16:53:53 -0800 1 --- It depends upon trans-attribute of entity bean B, if it is required or supported, EJB will execute entity bean B in same transaction of entity bean A 2 --- Assuming entity bean B is not executing in same transaction context of entity bean B, it will not affect the transaction of entity bean A. This is because EJB 2.0 does not support nested transactions, it support only flat. Thanks -- Vikram -Original Message- From: Nanik Tolaram [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 19, 2002 4:39 PM To: [EMAIL PROTECTED] Subject: Transaction question... Hi Friends, I have a question to ask about transaction. Here is the scenario... Client -- Servlet -- Entity Bean A (Container Managed Transaction and Container Managed Persistence) -- Bean B (Bean Managed Transaction and Bean Managed Persistence) I read in the spec EJB 2.0 section 17.6.1 it says .. the Container suspends any transaction that may be associated with the client .. (this would happen if the instance..), the container associates the method execution with this transaction correct me if I'm wrong please, does this mean that, 1. When Entity Bean A invoke the method on Entity Bean B the transaction that is currently attached to Entity Bean A is suspended and then it will resume the transaction again after it return back from Entity Bean B ? 2. Does the transaction in Entity Bean B affect the transaction in Entity Bean A ?, what I'm trying to say is if Entity Bean B rolled back for some reason does this roll back the transaction in Entity Bean A ? Thanks for the help and have a nice day Cheers Nanik _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. _ Chat with friends online, try MSN Messenger: http://messenger.msn.com === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: Transaction question...
As far as from EJB2.0 spec point of view entity bean can never execute under Bean Managed Transaction, it has to run under Container Managed Transaction. Please look into section 17.3.1. Thanks -- Vikram -Original Message- From: Nanik Tolaram [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 19, 2002 5:58 PM To: [EMAIL PROTECTED] Subject: Re: Transaction question... Hi Vikram, Thanks for the reply, but as you the transaction in Entity Bean B is Bean Managed Transaction and not Container Managed Transaction, as you mention that it all depends on the trans-attribute of the bean, which I assume is the trans-attribute in the deployment descriptor which in Entity Bean B there is none as it is a Bean Managed Transaction Correct me if I'm wrong. Thanks Nanik From: Vikrama Ditya [EMAIL PROTECTED] Reply-To: Vikrama Ditya [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Transaction question... Date: Tue, 19 Feb 2002 16:53:53 -0800 1 --- It depends upon trans-attribute of entity bean B, if it is required or supported, EJB will execute entity bean B in same transaction of entity bean A 2 --- Assuming entity bean B is not executing in same transaction context of entity bean B, it will not affect the transaction of entity bean A. This is because EJB 2.0 does not support nested transactions, it support only flat. Thanks -- Vikram -Original Message- From: Nanik Tolaram [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 19, 2002 4:39 PM To: [EMAIL PROTECTED] Subject: Transaction question... Hi Friends, I have a question to ask about transaction. Here is the scenario... Client -- Servlet -- Entity Bean A (Container Managed Transaction and Container Managed Persistence) -- Bean B (Bean Managed Transaction and Bean Managed Persistence) I read in the spec EJB 2.0 section 17.6.1 it says .. the Container suspends any transaction that may be associated with the client .. (this would happen if the instance..), the container associates the method execution with this transaction correct me if I'm wrong please, does this mean that, 1. When Entity Bean A invoke the method on Entity Bean B the transaction that is currently attached to Entity Bean A is suspended and then it will resume the transaction again after it return back from Entity Bean B ? 2. Does the transaction in Entity Bean B affect the transaction in Entity Bean A ?, what I'm trying to say is if Entity Bean B rolled back for some reason does this roll back the transaction in Entity Bean A ? Thanks for the help and have a nice day Cheers Nanik _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. _ Chat with friends online, try MSN Messenger: http://messenger.msn.com === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: SFSB Question
I keep coming across this problem. Usually I solve it by passing parameters to all
methods in a SLSB.
However in EJB 1.0, I seem to remember that user information (in addition to things
like UserPrincipal) could be added to the EJBContext, you could use getEnvironment()
to get a properties object.
Does anybody know why there is not a context object, like a servletContext or
sessionContext, in EJB.
Perhaps I am missing something?.. but that would seem to be a nice addition.
From reading the EJBContext JavaDoc, the deprecated method: getEnvironment(),
suggests using JNDI to get the environment variables. I have never seen anybody
caching data in this way. (One could use the principal object as a key to make the
data session specific)
Any Ideas.
Toby
On Fri, 25 Jan 2002 11:12:21 -0800, Alex Paransky
[EMAIL PROTECTED] wrote:
RE: SFSB QuestionPassing a parameter in to stateless session bean will not
help you, since the container is free to pool the beans as it wishes. So
when you are doing an Home.create() call the container is simply picking on
of existing free session bean objects from it's pool. If you did, somehow,
managed to initialize the session with the id of the user, it would only
confuse you later, since the same session would be used for a different
user.
The best method I can think of, is explicitly passing the parameters to each
call your client make on to the session bean. You can package those
parameters into a class called UserContext, for example, and make it easy to
create the context:
class UserContext implements java.io.Serializable {
String userId, sessionId, httpRequestId;
public static UserContext getContext(HttpServletRequest request) {...}
}
There are other methods such as using entity beans without persistence, or
using statefull session beans. Both of these, however, will reduce the load
balancing and fail over aspects of your system. Do you really want to
sacrifice these features for log4j? Perhaps. Perhaps Not. You need to
decide.
-AP_
-Original Message-
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Biske, Todd
Sent: Friday, January 25, 2002 6:35 AM
To: [EMAIL PROTECTED]
Subject: Re: SFSB Question
The initialization parameter that's needed is a logging context object
that allows us to use the NDC in log4j across VM's. An example would be
where we want the session id or user id associated with an HTTP request to
be prepended to all log messages generated in the processing of that
request. Within a VM, the NDC in log4j handles this. As soon as you make a
remote call, however, you're executing in a different thread and the
information in the NDC is lost.
-tb
-Original Message-
From: Alex Paransky [SMTP:[EMAIL PROTECTED]]
Sent: Thursday, January 24, 2002 5:35 PM
To: Biske, Todd; [EMAIL PROTECTED]
Subject:RE: SFSB Question
Stateless session beans imply that they cannot hold a state that is of
any meaning to the client. Thus it does not make sense for the client to
try to pass in any kind of initialization parameter. If you want to pass
extra information into the session, that should be done via ejb-jar.xml
descriptor in the session's environment. If you describe why you need to do
this, perhaps a better solution could be found.
State full sessions beans are expensive, and cannot be cached or re-used
by the container.
-AP_
-Original Message-
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Biske, Todd
Sent: Thursday, January 24, 2002 2:58 PM
To: [EMAIL PROTECTED]
Subject: SFSB Question
On the project I'm working on, we've got a situation where it would
extremely valuable to be able to have parameterized ejbCreate() methods on
our stateless session beans, but the spec doesn't allow for this (we could
put them in, but they'd never get invoked).
One alternative would be to use stateful session beans, which allow
this type of functionality. The client would still be using the session
bean in a stateless manner, however, e.g. one method call and it's done. Is
anyone aware of the potential overhead implications of making all of the
session beans stateful versus stateless? If it matters, the beans would be
deployed under WL 6.1.
The other alternative that we're currently heading down is to take the
parameter we'd like to pass in to ejbCreate() and add it to all of the
business methods defined in the remote/local interface.
Thoughts?
-tb
***
WARNING: All e-mail sent to and from this address will be received or
otherwise recorded by the A.G. Edwards corporate e-mail system and is
subject to archival, monitoring or review by, and/or disclosure to,
someone other than
Re: SFSB Question
No, EJB 1.0 didn't have what you are asking for. WebSphere 4 has a
proprietary add-on called Workspaces (as an enterprise extension) that is
exactly what you are looking for. I would also vote for adding a similar
construct to the spec!
/johan
-Original Message-
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Toby Weston
Sent: den 28 januari 2002 15:57
To: [EMAIL PROTECTED]
Subject: Re: SFSB Question
I keep coming across this problem. Usually I solve it by passing parameters
to all methods in a SLSB.
However in EJB 1.0, I seem to remember that user information (in addition to
things like UserPrincipal) could be added to the EJBContext, you could use
getEnvironment() to get a properties object.
Does anybody know why there is not a context object, like a servletContext
or sessionContext, in EJB.
Perhaps I am missing something?.. but that would seem to be a nice addition.
From reading the EJBContext JavaDoc, the deprecated method:
getEnvironment(), suggests using JNDI to get the environment variables. I
have never seen anybody caching data in this way. (One could use the
principal object as a key to make the data session specific)
Any Ideas.
Toby
On Fri, 25 Jan 2002 11:12:21 -0800, Alex Paransky
[EMAIL PROTECTED] wrote:
RE: SFSB QuestionPassing a parameter in to stateless session bean will not
help you, since the container is free to pool the beans as it wishes. So
when you are doing an Home.create() call the container is simply picking on
of existing free session bean objects from it's pool. If you did, somehow,
managed to initialize the session with the id of the user, it would only
confuse you later, since the same session would be used for a different
user.
The best method I can think of, is explicitly passing the parameters to
each
call your client make on to the session bean. You can package those
parameters into a class called UserContext, for example, and make it easy
to
create the context:
class UserContext implements java.io.Serializable {
String userId, sessionId, httpRequestId;
public static UserContext getContext(HttpServletRequest request) {...}
}
There are other methods such as using entity beans without persistence, or
using statefull session beans. Both of these, however, will reduce the
load
balancing and fail over aspects of your system. Do you really want to
sacrifice these features for log4j? Perhaps. Perhaps Not. You need to
decide.
-AP_
-Original Message-
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Biske, Todd
Sent: Friday, January 25, 2002 6:35 AM
To: [EMAIL PROTECTED]
Subject: Re: SFSB Question
The initialization parameter that's needed is a logging context object
that allows us to use the NDC in log4j across VM's. An example would be
where we want the session id or user id associated with an HTTP request to
be prepended to all log messages generated in the processing of that
request. Within a VM, the NDC in log4j handles this. As soon as you make
a
remote call, however, you're executing in a different thread and the
information in the NDC is lost.
-tb
-Original Message-
From: Alex Paransky [SMTP:[EMAIL PROTECTED]]
Sent: Thursday, January 24, 2002 5:35 PM
To: Biske, Todd; [EMAIL PROTECTED]
Subject:RE: SFSB Question
Stateless session beans imply that they cannot hold a state that is of
any meaning to the client. Thus it does not make sense for the client to
try to pass in any kind of initialization parameter. If you want to pass
extra information into the session, that should be done via ejb-jar.xml
descriptor in the session's environment. If you describe why you need to
do
this, perhaps a better solution could be found.
State full sessions beans are expensive, and cannot be cached or
re-used
by the container.
-AP_
-Original Message-
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Biske, Todd
Sent: Thursday, January 24, 2002 2:58 PM
To: [EMAIL PROTECTED]
Subject: SFSB Question
On the project I'm working on, we've got a situation where it would
extremely valuable to be able to have parameterized ejbCreate() methods on
our stateless session beans, but the spec doesn't allow for this (we could
put them in, but they'd never get invoked).
One alternative would be to use stateful session beans, which allow
this type of functionality. The client would still be using the session
bean in a stateless manner, however, e.g. one method call and it's done.
Is
anyone aware of the potential overhead implications of making all of the
session beans stateful versus stateless? If it matters, the beans would be
deployed under WL 6.1.
The other alternative that we're currently heading down is to take
the
parameter we'd like to pass in to ejbCreate
Re: SFSB Question
Title: RE: SFSB Question The initialization parameter that's needed is a logging context object that allows us to use the NDC in log4j across VM's. An example would be where we want the session id or user id associated with an HTTP request to be prepended to all log messages generated in the processing of that request. Within a VM, the NDC in log4j handles this. As soon as you make a remote call, however, you're executing in a different thread and the information in the NDC is lost. -tb -Original Message- From: Alex Paransky [SMTP:[EMAIL PROTECTED]] Sent: Thursday, January 24, 2002 5:35 PM To: Biske, Todd; [EMAIL PROTECTED] Subject: RE: SFSB Question Stateless session beans imply that they cannot hold a state that is of any meaning to the client. Thus it does not make sense for the client to try to pass in any kind of initialization parameter. If you want to pass extra information into the session, that should be done via ejb-jar.xml descriptor in the session's environment. If you describe why you need to do this, perhaps a better solution could be found. State full sessions beans are expensive, and cannot be cached or re-used by the container. -AP_ -Original Message- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Biske, Todd Sent: Thursday, January 24, 2002 2:58 PM To: [EMAIL PROTECTED] Subject: SFSB Question On the project I'm working on, we've got a situation where it would extremely valuable to be able to have parameterized ejbCreate() methods on our stateless session beans, but the spec doesn't allow for this (we could put them in, but they'd never get invoked). One alternative would be to use stateful session beans, which allow this type of functionality. The client would still be using the session bean in a stateless manner, however, e.g. one method call and it's done. Is anyone aware of the potential overhead implications of making all of the session beans stateful versus stateless? If it matters, the beans would be deployed under WL 6.1. The other alternative that we're currently heading down is to take the parameter we'd like to pass in to ejbCreate() and add it to all of the business methods defined in the remote/local interface. Thoughts? -tb *** WARNING: All e-mail sent to and from this address will be received or otherwise recorded by the A.G. Edwards corporate e-mail system and is subject to archival, monitoring or review by, and/or disclosure to, someone other than the recipient. *** *** WARNING: All e-mail sent to and from this address will be received or otherwise recorded by the A.G. Edwards corporate e-mail system and is subject to archival, monitoring or review by, and/or disclosure to, someone other than the recipient. ***
Re: SFSB Question
Title: RE: SFSB Question
Passing a parameter in to stateless session bean will not help you, since
the container is free to pool the beans as it wishes. So when you are
doing an Home.create() call the container is simply picking on of existing free
session bean objects from it's pool. If you
did, somehow, managed to initialize the session with the id of the user, it
would only confuse you later, since the same session would be used for a
different user.
The best method I can think of, is
explicitly passing the parameters to each call your client make on to the
session bean. You can package those parameters into a class called
UserContext, for example, and make it easy to create the
context:
class UserContext implements
java.io.Serializable {
String userId, sessionId,
httpRequestId;
public static UserContext
getContext(HttpServletRequest request)
{...}
}
There are other methods such as using
entity beans without persistence, or using statefull session beans. Both
of these, however,will reduce the load balancing and fail over aspects of
your system. Do you really want to sacrifice these features for
log4j? Perhaps. Perhaps Not. You need to
decide.
-AP_
-Original Message-From: A mailing list for
Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On
Behalf Of Biske, ToddSent: Friday, January 25, 2002 6:35
AMTo: [EMAIL PROTECTED]Subject: Re: SFSB
Question
The initialization parameter that's
needed is a logging context object that allows us to use the NDC in log4j
across VM's. An example would be where we want the session id or user id
associated with an HTTP request to be prepended to all log messages generated
in the processing of that request. Within a VM, the NDC in log4j handles
this. As soon as you make a remote call, however, you're executing in a
different thread and the information in the NDC is lost.
-tb
-Original Message- From: Alex
Paransky [SMTP:[EMAIL PROTECTED]] Sent: Thursday, January 24, 2002 5:35 PM To: Biske,
Todd; [EMAIL PROTECTED] Subject: RE: SFSB Question
Stateless session beans imply that
they cannot hold a state that is of any meaning to the client. Thus it
does not make sense for the client to try to pass in any kind of
initialization parameter. If you want to pass extra information into
the session, that should be done via ejb-jar.xml descriptor in the session's
environment. If you describe why you need to do this, perhaps a better
solution could be found.
State
full sessions beans are expensive, and cannot be cached or re-used by the
container. -AP_
-Original Message-From: A mailing
list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Biske,
ToddSent: Thursday, January 24, 2002 2:58 PMTo:
[EMAIL PROTECTED]Subject: SFSB
Question
On the project I'm working on, we've got a
situation where it would extremely valuable to be able to have
parameterized ejbCreate() methods on our stateless session beans, but the
spec doesn't allow for this (we could put them in, but they'd never get
invoked).
One alternative would be to use stateful
session beans, which allow this type of functionality. The client
would still be using the session bean in a stateless manner, however, e.g.
one method call and it's done. Is anyone aware of the potential
overhead implications of making all of the session beans stateful versus
stateless? If it matters, the beans would be deployed under WL
6.1.
The other alternative that we're currently
heading down is to take the parameter we'd like to pass in to ejbCreate()
and add it to all of the business methods defined in the remote/local
interface.
Thoughts?-tb
***WARNING:
All e-mail sent to and from this address will be received orotherwise
recorded by the A.G. Edwards corporate e-mail system and issubject to
archival, monitoring or review by, and/or disclosure to,someone other
than the
recipient.**WARNING:
All e-mail sent to and from this address will be received orotherwise
recorded by the A.G. Edwards corporate e-mail system and issubject to
archival, monitoring or review by, and/or disclosure to,someone other than
the
recipient.***
Re: SFSB Question
Use an entity bean with BMP. Take all the data you wanted to pass as a parameter, make a primary key class containing that data. ejbLoad/ejbStore can be empty, as you don't need any persistent fields. In your business methods where you want to access the data that was passed to ejbCreate, call entityContext.getPrimaryKey() to get the values. Biske, Todd wrote: On the project I'm working on, we've got a situation where it would extremely valuable to be able to have parameterized ejbCreate() methods on our stateless session beans, but the spec doesn't allow for this (we could put them in, but they'd never get invoked). One alternative would be to use stateful session beans, which allow this type of functionality. The client would still be using the session bean in a stateless manner, however, e.g. one method call and it's done. Is anyone aware of the potential overhead implications of making all of the session beans stateful versus stateless? If it matters, the beans would be deployed under WL 6.1. The other alternative that we're currently heading down is to take the parameter we'd like to pass in to ejbCreate() and add it to all of the business methods defined in the remote/local interface. Thoughts? -tb *** WARNING: All e-mail sent to and from this address will be received or otherwise recorded by the A.G. Edwards corporate e-mail system and is subject to archival, monitoring or review by, and/or disclosure to, someone other than the recipient. *** -- ___ Evan IrelandSybase EAServer Engineering [EMAIL PROTECTED] Wellington, New Zealand+64 4 934-5856 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: SFSB Question
Title: SFSB Question Stateless session beans imply that they cannot hold a state that is of any meaning to the client. Thus it does not make sense for the client to try to pass in any kind of initialization parameter. If you want to pass extra information into the session, that should be done via ejb-jar.xml descriptor in the session's environment. If you describe why you need to do this, perhaps a better solution could be found. State full sessions beans are expensive, and cannot be cached or re-used by the container. -AP_ -Original Message-From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Biske, ToddSent: Thursday, January 24, 2002 2:58 PMTo: [EMAIL PROTECTED]Subject: SFSB Question On the project I'm working on, we've got a situation where it would extremely valuable to be able to have parameterized ejbCreate() methods on our stateless session beans, but the spec doesn't allow for this (we could put them in, but they'd never get invoked). One alternative would be to use stateful session beans, which allow this type of functionality. The client would still be using the session bean in a stateless manner, however, e.g. one method call and it's done. Is anyone aware of the potential overhead implications of making all of the session beans stateful versus stateless? If it matters, the beans would be deployed under WL 6.1. The other alternative that we're currently heading down is to take the parameter we'd like to pass in to ejbCreate() and add it to all of the business methods defined in the remote/local interface. Thoughts? -tb ***WARNING: All e-mail sent to and from this address will be received orotherwise recorded by the A.G. Edwards corporate e-mail system and issubject to archival, monitoring or review by, and/or disclosure to,someone other than the recipient.***
Re: SFSB Question
Also given the fact that entity beans can be shared by multiple clients while session beans cannot. Lets say I have a stateful session bean and the create method being ejbobject create(int accId) A person logs in with accountId 1 (A stateful session bean instance created - SF1) At the same time his wife logs in accessing this account(Another stateful session bean created - SF2) now SF1.isIdentical(SF2) will return false. while if is an entity bean they will share the same primary key and hence the same entity bean instance. I was wondering if this can cause any issues!!! Any comments?? - Rajeev Dave -Original Message- From: Evan Ireland [mailto:[EMAIL PROTECTED]] Sent: Friday, January 25, 2002 4:39 AM To: [EMAIL PROTECTED] Subject: Re: SFSB Question Use an entity bean with BMP. Take all the data you wanted to pass as a parameter, make a primary key class containing that data. ejbLoad/ejbStore can be empty, as you don't need any persistent fields. In your business methods where you want to access the data that was passed to ejbCreate, call entityContext.getPrimaryKey() to get the values. Biske, Todd wrote: On the project I'm working on, we've got a situation where it would extremely valuable to be able to have parameterized ejbCreate() methods on our stateless session beans, but the spec doesn't allow for this (we could put them in, but they'd never get invoked). One alternative would be to use stateful session beans, which allow this type of functionality. The client would still be using the session bean in a stateless manner, however, e.g. one method call and it's done. Is anyone aware of the potential overhead implications of making all of the session beans stateful versus stateless? If it matters, the beans would be deployed under WL 6.1. The other alternative that we're currently heading down is to take the parameter we'd like to pass in to ejbCreate() and add it to all of the business methods defined in the remote/local interface. Thoughts? -tb *** WARNING: All e-mail sent to and from this address will be received or otherwise recorded by the A.G. Edwards corporate e-mail system and is subject to archival, monitoring or review by, and/or disclosure to, someone other than the recipient. *** -- ___ Evan IrelandSybase EAServer Engineering [EMAIL PROTECTED] Wellington, New Zealand+64 4 934-5856 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: A question about a CMP entitybean 's remove method?
how do you delete the article? from what you've said, I'm guessing the session bean does a sql delete? if thats the case, then you're not using it properly. the container will throw a NoSuchObjectException if there is an entity bean in memory, but the record has been deleted from the database. To remove the article, do a articleHome.findByPrimaryKey(articleId).remove(); hth dim On Mon, 3 Dec 2001, sharetop YC wrote: Dear all. I write a simple CMP entitybean example. the structure of application is: A entityBean(CMP) ArticleEJB, A sessionBean(stateful) ArticleManagerEJB,he has a method deleteArticle(long id) A sessionBean(stateless) ArticleShowerEJB,he has a method list(int col) the shower list all article in database,and manager delete one article. I list all article by column,right.I delete one article by it's id,right. then I list again, throw a NoSuchObjectException I output the error message to system.out,as follow: -ejbActivate called. -ejbLoad called. -ejbStore called. -ejbStore called. -ejbStore called.-list method be called ok. -ejbRemove called. -this is ok too,when i delete a article. -ejbActivate called. -then error occurred, when i list record from database again.why active it? but it be delete from database? java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: java.rmi.RemoteException: nested exception is: java.rmi.NoSuchObjectException: CORBA OBJECT_NOT_EXIST 9998 Maybe; nested exception is: org.omg.CORBA.OBJECT_NOT_EXIST: minor code: 9998 completed: Maybe; nested exception is: java.rmi.NoSuchObjectException: CORBA OBJECT_NOT_EXIST 9998 Maybe; nested exception is: org.omg.CORBA.OBJECT_NOT_EXIST: minor code: 9998 completed: Maybe java.rmi.RemoteException: nested exception is: java.rmi.NoSuchObjectException: CORBA OBJECT_NOT_EXIST 9998 Maybe; nested exception is: org.omg.CORBA.OBJECT_NOT_EXIST: minor code: 9998 completed: Maybe; nested exception is: java.rmi.NoSuchObjectException: CORBA OBJECT_NOT_EXIST 9998 Maybe; nested exception is: org.omg.CORBA.OBJECT_NOT_EXIST: minor code: 9998 completed: Maybe java.rmi.NoSuchObjectException: CORBA OBJECT_NOT_EXIST 9998 Maybe; nested exception is: org.omg.CORBA.OBJECT_NOT_EXIST: minor code: 9998 completed: Maybe org.omg.CORBA.OBJECT_NOT_EXIST: minor code: 9998 completed: Maybe no stack trace available Please help me. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: A question about a CMP entitybean 's remove method?
The ArticleEJB is a CMP entitybean,so the remove() method is empty.
and ArticleManagerEJB is a sessionbean, he call the ArticleEJB's remove to delete a
article from database,the source code is :
public void deleteArticle(long id){
Article article;
try{
article = articleHome.findByPrimaryKey(new Long(id));
article.remove();
article=null;
}
catch(Exception ex){
throw new EJBException(ex);
}
}
application run here is right,no exception report.
but when i list article again, the NoSuchObjectException was throwed.
the list method source is :
public String list(int col){
try{
Collection collectionArticle = articleHome.findByColumn(col);
Object[] articles = collectionArticle.toArray();
StringBuffer res = new StringBuffer();
res.append(article_list);
for(int i=0;iarticles.length;i++){
res.append(article);
ArticleInfo info = ((Article)articles[i]).getArticle();
res.append(id+info.id+/id);
res.append(column+info.colum+/column);
res.append(title+info.title+/title);
res.append(author+info.author+/author);
res.append(email+info.email+/email);
res.append(date+info.cdate+/date);
res.append(editor+info.editor+/editor);
res.append(/article);
}
res.append(/article_list);
return res.toString();
}
catch(Exception ex){
throw new EJBException(ex);
}
}
thank you very much.
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff EJB-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
Re: A question about a CMP entitybean 's remove method?
hmmm... that is odd... not sure I'm going to be able to offer any more
immediately... from what I understand of what you're describing it all
should be ok...
both methods are in the session bean right? what app server are you
running on?
cheers
dim
On Mon, 3 Dec 2001, sharetop YC wrote:
The ArticleEJB is a CMP entitybean,so the remove() method is empty.
and ArticleManagerEJB is a sessionbean, he call the ArticleEJB's remove to delete a
article from database,the source code is :
public void deleteArticle(long id){
Article article;
try{
article = articleHome.findByPrimaryKey(new Long(id));
article.remove();
article=null;
}
catch(Exception ex){
throw new EJBException(ex);
}
}
application run here is right,no exception report.
but when i list article again, the NoSuchObjectException was throwed.
the list method source is :
public String list(int col){
try{
Collection collectionArticle = articleHome.findByColumn(col);
Object[] articles = collectionArticle.toArray();
StringBuffer res = new StringBuffer();
res.append(article_list);
for(int i=0;iarticles.length;i++){
res.append(article);
ArticleInfo info = ((Article)articles[i]).getArticle();
res.append(id+info.id+/id);
res.append(column+info.colum+/column);
res.append(title+info.title+/title);
res.append(author+info.author+/author);
res.append(email+info.email+/email);
res.append(date+info.cdate+/date);
res.append(editor+info.editor+/editor);
res.append(/article);
}
res.append(/article_list);
return res.toString();
}
catch(Exception ex){
throw new EJBException(ex);
}
}
thank you very much.
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff EJB-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
Re: A question about a CMP entitybean 's remove method?
keep the discussion ont he list so all can benefit (o:
On Tue, 4 Dec 2001, sharetop wrote:
Yes, deleteArticle() in the ManagerEJB( a stateful sessionbean) and
list() in the ShowerEJB(a stateless sessionbean).
I use the j2sdkee1.3,and database is mysql.what matter with them?
I dont know - possibly nothing.
are both methods called int he same tx context, or do you call one then
the other? I really have no idea why its not working... and am just
trying to think of things that might lead you to more information...
cheers
dim
hmmm... that is odd... not sure I'm going to be able to offer any more
immediately... from what I understand of what you're describing it all
should be ok...
both methods are in the session bean right? what app server are you
running on?
cheers
dim
On Mon, 3 Dec 2001, sharetop YC wrote:
The ArticleEJB is a CMP entitybean,so the remove() method is empty.
and ArticleManagerEJB is a sessionbean, he call the ArticleEJB's remove to delete
a article from database,the source code is :
public void deleteArticle(long id){
Article article;
try{
article = articleHome.findByPrimaryKey(new Long(id));
article.remove();
article=null;
}
catch(Exception ex){
throw new EJBException(ex);
}
}
application run here is right,no exception report.
but when i list article again, the NoSuchObjectException was throwed.
the list method source is :
public String list(int col){
try{
Collection collectionArticle = articleHome.findByColumn(col);
Object[] articles = collectionArticle.toArray();
StringBuffer res = new StringBuffer();
res.append(article_list);
for(int i=0;iarticles.length;i++){
res.append(article);
ArticleInfo info = ((Article)articles[i]).getArticle();
res.append(id+info.id+/id);
res.append(column+info.colum+/column);
res.append(title+info.title+/title);
res.append(author+info.author+/author);
res.append(email+info.email+/email);
res.append(date+info.cdate+/date);
res.append(editor+info.editor+/editor);
res.append(/article);
}
res.append(/article_list);
return res.toString();
}
catch(Exception ex){
throw new EJBException(ex);
}
}
thank you very much.
ÖÂ
Àñ£¡
sharetop
[EMAIL PROTECTED]
==To
unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff EJB-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
Re: PetStore question
EJBException is a runtime exception. So why do you need to mention it in throws clause of method signature. regards Nikhil. -Original Message- From: Cornel Antohi [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 17, 2001 3:20 PM To: [EMAIL PROTECTED] Subject: PetStore question Most of the EJBs throw EJBException in the body of methods, but the throw clause is not present in method signature This problem gives me a lot of errors ! I have 1.1.2 version. ==To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: PetStore question
Visual Age tells me that it can't compile the sources because the exception is not declared - Original Message - From: Nikhil sharma [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 17, 2001 11:31 AM Subject: Re: PetStore question EJBException is a runtime exception. So why do you need to mention it in throws clause of method signature. regards Nikhil. -Original Message- From: Cornel Antohi [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 17, 2001 3:20 PM To: [EMAIL PROTECTED] Subject: PetStore question Most of the EJBs throw EJBException in the body of methods, but the throw clause is not present in method signature This problem gives me a lot of errors ! I have 1.1.2 version. To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: PetStore question
Visual Age 3.x incorrectly defines the EJBException class as a subclass of Exception instead of RuntimeException. It is fixed in VAJ 4 / WebSphere 4. Visual Age 3.x is in this respect not compliant to any existing EJB spec. /Johan -Original Message- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Cornel Antohi Sent: den 17 oktober 2001 14:44 To: [EMAIL PROTECTED] Subject: Re: PetStore question Visual Age tells me that it can't compile the sources because the exception is not declared - Original Message - From: Nikhil sharma [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 17, 2001 11:31 AM Subject: Re: PetStore question EJBException is a runtime exception. So why do you need to mention it in throws clause of method signature. regards Nikhil. -Original Message- From: Cornel Antohi [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 17, 2001 3:20 PM To: [EMAIL PROTECTED] Subject: PetStore question Most of the EJBs throw EJBException in the body of methods, but the throw clause is not present in method signature This problem gives me a lot of errors ! I have 1.1.2 version. To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: PetStore question
In fact if you add a throws EJBException to the interface you'll find you can't deploy the beans on some app servers, JBoss comes to mind immediately. Cheers -Original Message- From: Cornel Antohi To: [EMAIL PROTECTED] Sent: 10/17/01 8:44 AM Subject: Re: PetStore question Visual Age tells me that it can't compile the sources because the exception is not declared - Original Message - From: Nikhil sharma [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 17, 2001 11:31 AM Subject: Re: PetStore question EJBException is a runtime exception. So why do you need to mention it in throws clause of method signature. regards Nikhil. -Original Message- From: Cornel Antohi [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 17, 2001 3:20 PM To: [EMAIL PROTECTED] Subject: PetStore question Most of the EJBs throw EJBException in the body of methods, but the throw clause is not present in method signature This problem gives me a lot of errors ! I have 1.1.2 version. To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: Design Question : XML descriptions session beans (LONG)
Jerome, IMHO, EJB's should never accept arguments that represent an XML document! The reasons are simple: - XML is fat and RMI serialzation does not help. The most popular method is for the EJB to accept a String or File as a parameter which represents the XML document. The number of bytes that are consumed goes up a zillion percent when marshalling data in this format as opposed to traditional RMI object serialization. Case in point: myInt8/myInt to transport int value=8? Things get worse the larger your Object is... - XML parsing is intensive, especially DOM. The place to do this processing is NOT in an EJB container. - It's bad design semantics and bad OO, i.e. String returnDoc = myBean.doSomething(String xmlDoc); Says nothing about what doSomething does or the types of arguments it takes, DTD's help but the contract is really not clear... Better design: let your presentation layer handle the data stream (via servlets) and invoke EJB as needed. OR you can use SOAP that delegates invocations to EJBS. Don't pass XML to EJBS!! /opinion hope this helps, peter On Fri, 27 Jul 2001 09:39:06 +0200 [EMAIL PROTECTED] wrote: Hi all EJB gurus, sorry for any incovenience if my question seems stupid but I've got a question dealing with design of my EJB (sessions): I'd like to open my business services to as many apps as possible so I think that getting views of my entities using XML descriptions could be a great way for this. SO I thought that session beans could expose such services offering XML descriptions of underlying entities using ids or names. But the little confusing (for me) EJB specs tends to convince me that my session bean should not handle IO streams. Note: One of my beans should provide a file (it is its only service, that 's its job!!), is it a design fault ? Transactions concurrency are not a problem for this bean, is it possible ? It seems that some containers could prevent me accessing to local Filessytem. All clues welcomed!!! Am I wrong . Has someone implemented such design ? For deployment reasons I'd like to avoid using a servlet engine for such service I'd like to use Castor/XML Java/XML mapping tier for such job, in order to avoid coding writeToXML() methods. All experience feedback welcomed Cheers Jerome PS: excsue me for my poor english written == To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST.For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. Peter Braswell Utopian Software [EMAIL PROTECTED] 757.560.8867 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: Design Question : XML descriptions session beans (LONG)
I think EJB 3.0 or beyond should address internet capability (web service integration). Currently EJB clusters are restricted to LAN usage but the internet service paradigm has amazing capability and is taking hold. I would advocate in the same manner that MDB's were introduced, that there be internet beans - these are EJB's that are web services themselves in a sense and do communicate with other (remote) web services via XML advertisement and discovery. This could offer some powerful capabilities and a decent platform interface. (Just my $.02) From: Peter Braswell [EMAIL PROTECTED] Reply-To: Peter Braswell [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Design Question : XML descriptions session beans (LONG) Date: Fri, 27 Jul 2001 15:39:51 GMT Jerome, IMHO, EJB's should never accept arguments that represent an XML document! The reasons are simple: - XML is fat and RMI serialzation does not help. The most popular method is for the EJB to accept a String or File as a parameter which represents the XML document. The number of bytes that are consumed goes up a zillion percent when marshalling data in this format as opposed to traditional RMI object serialization. Case in point: myInt8/myInt to transport int value=8? Things get worse the larger your Object is... - XML parsing is intensive, especially DOM. The place to do this processing is NOT in an EJB container. - It's bad design semantics and bad OO, i.e. String returnDoc = myBean.doSomething(String xmlDoc); Says nothing about what doSomething does or the types of arguments it takes, DTD's help but the contract is really not clear... Better design: let your presentation layer handle the data stream (via servlets) and invoke EJB as needed. OR you can use SOAP that delegates invocations to EJBS. Don't pass XML to EJBS!! /opinion hope this helps, peter On Fri, 27 Jul 2001 09:39:06 +0200 [EMAIL PROTECTED] wrote: Hi all EJB gurus, sorry for any incovenience if my question seems stupid but I've got a question dealing with design of my EJB (sessions): I'd like to open my business services to as many apps as possible so I think that getting views of my entities using XML descriptions could be a great way for this. SO I thought that session beans could expose such services offering XML descriptions of underlying entities using ids or names. But the little confusing (for me) EJB specs tends to convince me that my session bean should not handle IO streams. Note: One of my beans should provide a file (it is its only service, that 's its job!!), is it a design fault ? Transactions concurrency are not a problem for this bean, is it possible ? It seems that some containers could prevent me accessing to local Filessytem. All clues welcomed!!! Am I wrong . Has someone implemented such design ? For deployment reasons I'd like to avoid using a servlet engine for such service I'd like to use Castor/XML Java/XML mapping tier for such job, in order to avoid coding writeToXML() methods. All experience feedback welcomed Cheers Jerome PS: excsue me for my poor english written == To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST.For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. Peter Braswell Utopian Software [EMAIL PROTECTED] 757.560.8867 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: Design Question : XML descriptions session beans (LONG)
- Original Message - From: John Harby [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 27, 2001 9:27 PM Subject: Re: Design Question : XML descriptions session beans (LONG) Currently EJB clusters are restricted to LAN usage Isnt' this a limitation of a particular implementation ? Or are you saying people prefer using it that way ? From: Peter Braswell [EMAIL PROTECTED] Reply-To: Peter Braswell [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Design Question : XML descriptions session beans (LONG) Date: Fri, 27 Jul 2001 15:39:51 GMT Jerome, IMHO, EJB's should never accept arguments that represent an XML document! The reasons are simple: - XML is fat and RMI serialzation does not help. The most popular method is for the EJB to accept a String or File as a parameter which represents the XML document. The number of bytes that are consumed goes up a zillion percent when marshalling data in this format as opposed to traditional RMI object serialization. Case in point: myInt8/myInt to transport int value=8? Things get worse the larger your Object is... - XML parsing is intensive, especially DOM. The place to do this processing is NOT in an EJB container. - It's bad design semantics and bad OO, i.e. String returnDoc = myBean.doSomething(String xmlDoc); Says nothing about what doSomething does or the types of arguments it takes, DTD's help but the contract is really not clear... Better design: let your presentation layer handle the data stream (via servlets) and invoke EJB as needed. OR you can use SOAP that delegates invocations to EJBS. Don't pass XML to EJBS!! /opinion hope this helps, peter On Fri, 27 Jul 2001 09:39:06 +0200 [EMAIL PROTECTED] wrote: Hi all EJB gurus, sorry for any incovenience if my question seems stupid but I've got a question dealing with design of my EJB (sessions): I'd like to open my business services to as many apps as possible so I think that getting views of my entities using XML descriptions could be a great way for this. SO I thought that session beans could expose such services offering XML descriptions of underlying entities using ids or names. But the little confusing (for me) EJB specs tends to convince me that my session bean should not handle IO streams. Note: One of my beans should provide a file (it is its only service, that 's its job!!), is it a design fault ? Transactions concurrency are not a problem for this bean, is it possible ? It seems that some containers could prevent me accessing to local Filessytem. All clues welcomed!!! Am I wrong . Has someone implemented such design ? For deployment reasons I'd like to avoid using a servlet engine for such service I'd like to use Castor/XML Java/XML mapping tier for such job, in order to avoid coding writeToXML() methods. All experience feedback welcomed Cheers Jerome PS: excsue me for my poor english written == To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST.For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. Peter Braswell Utopian Software [EMAIL PROTECTED] 757.560.8867 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: A question about singleton
Another option is to use instance fields of a stateless session bean as cache. You will get one set of your country data for each instance in the method-ready-pool, but is that actually a problem? It may be a good trade-off between memory usage and concurrency conflicts. /Johan -Original Message- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Ken Delong Sent: den 7 juni 2001 19:34 To: [EMAIL PROTECTED] Subject: A question about singleton Someone posted this as a possible interview question on the J2EE list: Ex: I have a list of country codes and country names. I only want to read the list form the database once a day (since new countries are not created very often) and only want one version in memory for all to share. How would you write your application? I can see several options here: 1. Write a regular old Singleton - but now you'll have one copy per JVM, which doesn't satisfy the 'read once a day' requirement. 2. Use a JNDI javax.naming.Reference to bind the singleton object into JNDI, and look it up that way. I don't know enough about Reference to fully understand the cross-JVM issues here. 3. External RMI-based server, bound into JNDI. Satisfies all requirements, but a little slow (YARC - yet another remote call). 4. A single entity bean instance with Commit Option A (caching) or one of the proprietary read-only or supressed ejbLoad() entity beans that various vendors support. Any other solutions? -- Kenneth DeLong Senior Consultant Valtech, Inc. Cell phone: 510-517-5839 Every complex problem has a simple answer - and it's always wrong. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: A question about singleton
Kevin Mukhar wrote: If you wanted to use a singleton to hold a reference to a bean ... I am starting to understand what you mean by a singleton. The client of the singleton enterprise bean does not access it using home.create. Instead the singleton is implemented either in the client or via a wrapper. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: A question about singleton
This is an interesting view of singletons initiated by Kent Beck - http://c2.com/cgi/wiki?SingletonsAreEvil. I think it applies especially in the case of distributed systems. From: Glyn Normington [EMAIL PROTECTED] Reply-To: Glyn Normington [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: A question about singleton Date: Mon, 11 Jun 2001 03:17:55 -0700 Kevin Mukhar wrote: If you wanted to use a singleton to hold a reference to a bean ... I am starting to understand what you mean by a singleton. The client of the singleton enterprise bean does not access it using home.create. Instead the singleton is implemented either in the client or via a wrapper. _ Get your FREE download of MSN Explorer at http://explorer.msn.com === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: A question about singleton
Kevin, the more dangerous issue isn't when your static initializer fires,
but if it could fire more than once simultaneously--I wrote a paper on this
topic, When is a static not a static?, at
http://www.javageeks.com/Papers/JavaStatics/index.html. The danger is that
if the server maintains logical separation of loaded classes (which almost
all servers support, to provide transparent versioning of EJBs without
taking the server down), then you could have multiple copies of your
Singleton running around simultaneously.
Ted Neward
{.NET||Java} Instructor, DevelopMentor (http://www.develop.com)
http://www.javageeks.com/~tneward/index.html
-Original Message-
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Kevin Mukhar
Sent: Friday, June 08, 2001 12:38 PM
To: [EMAIL PROTECTED]
Subject: Re: [EJB-INT] A question about singleton
Kovács Péter wrote:
I like your solution, but I am always uneasy about using
static initalizers
when my component sits on top of a more or less complex
system.
After my previous reply, I did realize that there is one drawback
to what I am
doing. If my static initializer just initialized a variable to
some literal
value, there would be no problem. However, in my EJB, I am initializing a
static variable based on the results of making a remote call to
another server
(an LDAP server). If the server is down, then my EJB is not properly
initialized. My bean is a little more complex because it needs
logic to deal
with this situation. However, this is a conscious tradeoff that I chose to
accept: I minimized the number of calls to the server for data that is
essentially constant at the cost of a more complex EJB.
==
=
To unsubscribe, send email to [EMAIL PROTECTED] and include
in the body
of the message signoff EJB-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff EJB-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
Re: A question about singleton
Ted,
Good points. You also have to watch out for class garbage collecrtion.
Ted Neward wrote:
Kevin, the more dangerous issue isn't when your static initializer fires,
but if it could fire more than once simultaneously--I wrote a paper on this
topic, When is a static not a static?, at
http://www.javageeks.com/Papers/JavaStatics/index.html. The danger is that
if the server maintains logical separation of loaded classes (which almost
all servers support, to provide transparent versioning of EJBs without
taking the server down), then you could have multiple copies of your
Singleton running around simultaneously.
Ted Neward
{.NET||Java} Instructor, DevelopMentor (http://www.develop.com)
http://www.javageeks.com/~tneward/index.html
-Original Message-
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Kevin Mukhar
Sent: Friday, June 08, 2001 12:38 PM
To: [EMAIL PROTECTED]
Subject: Re: [EJB-INT] A question about singleton
Kovács Péter wrote:
I like your solution, but I am always uneasy about using
static initalizers
when my component sits on top of a more or less complex
system.
After my previous reply, I did realize that there is one drawback
to what I am
doing. If my static initializer just initialized a variable to
some literal
value, there would be no problem. However, in my EJB, I am initializing a
static variable based on the results of making a remote call to
another server
(an LDAP server). If the server is down, then my EJB is not properly
initialized. My bean is a little more complex because it needs
logic to deal
with this situation. However, this is a conscious tradeoff that I chose to
accept: I minimized the number of calls to the server for data that is
essentially constant at the cost of a more complex EJB.
==
=
To unsubscribe, send email to [EMAIL PROTECTED] and include
in the body
of the message signoff EJB-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff EJB-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
--
Evan Ireland Sybase EAServer Engineering[EMAIL PROTECTED]
Wellington, New Zealand +64 4 934-5856
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff EJB-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
Re: A question about singleton
1. Write a regular old Singleton This probably involves updating static contrary to the restriction in section 18.1.2 of the EJB 1.1 spec and can lead to inconsistent runtime semantics, although it can be argued that this restriction is only intended to apply to fields of the enterprise bean class itself and not those of 'helper' classes. In multi-threaded JVM EJB implementations you would need to be careful to make the singleton code thread-safe. In environments that ensure application isolation, such as CICS TS v2.1, if an application updates static there is an undesirable performance penalty as the JVM cannot be reset to a clean state for the next transaction and must be terminated at end of transaction. Glyn Normington === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: A question about singleton
Glyn Normington wrote: 1. Write a regular old Singleton This probably involves updating static contrary to the restriction in section 18.1.2 of the EJB 1.1 spec and can lead to inconsistent runtime semantics, although it can be argued that this restriction is only intended to apply to fields of the enterprise bean class itself and not those of 'helper' classes. To be clear, the 1.1 spec only prohibits read/write static fields. Here is the relevant section: An enterprise Bean must not use read/write static fields. Using read-only static fields is allowed. Therefore, it is recommended that all static fields in the enterprise bean class be declared as final. The classic pattern for the Singleton class uses a read-only static field to hold the Singleton reference, so it would be allowed. The rationale for this restriction would apply to helper classes as well, so even though the spec refers specifically to EJBs, I would argue that the restriction against read/write statics applies to helper classes. Unfortunately, helper classes are not always written specifically for EJBs and the developer may not be able to modify the helper class as needed. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: A question about singleton
Kevin Mukhar wrote: The classic pattern for the Singleton class uses a read-only static field to hold the Singleton reference, ... I suppose the initial expression for the static field would be like this: BeanX singleton = ((BeanXHome)javax.rmi.PortableRemoteObject.narrow( new InitialContext().lookup(path), BeanXHome.class)).create(parms) but where would this code would be placed. It's no good inside ejbCreate as ejbCreate is already running on a new instance rather than the singleton. So how could you implement the singleton portably? I would argue that the restriction against read/write statics applies to helper classes. I agree. CICS treats enterprise beans and their helper classes the same in this respect. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: A question about singleton
I like your solution, but I am always uneasy about using static initalizers
when my component sits on top of a more or less complex system. As far as I
know, there is not much in the EJB spec (1.1) on when the bean classes are
loaded. So you are probably limited to doing tasks that do not need more
than the base java classes.
-Original Message-
From: Kevin Mukhar [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 08, 2001 6:20 PM
To: [EMAIL PROTECTED]
Subject: Re: A question about singleton
Glyn Normington wrote:
Kevin Mukhar wrote:
The classic pattern for the Singleton class uses a read-only static field
to
hold the Singleton reference, ...
I suppose the initial expression for the static field would be like this:
BeanX singleton = ((BeanXHome)javax.rmi.PortableRemoteObject.narrow(
new InitialContext().lookup(path), BeanXHome.class)).create(parms)
but where would this code would be placed. It's no good inside ejbCreate
as ejbCreate is already running on a new instance rather than the
singleton.
So how could you implement the singleton portably?
This is how I currently load a static member in a bean I developed:
public class MyBean implements SessionBean {
static Hashtable keyValuePairs = createHashtable();
static Hashtable createHashtable() {
Hashtable h = new Hashtable();
//... code to fill hashtable
return h;
}
//... rest of bean methods
}
This code will execute when the class is loaded by the JVM, initializing the
static reference. It will execute before the constructor is called and
before
the call to ejbCreate(). If you wanted to use a singleton to hold a
reference
to a bean, the method would need to include a try-catch block, or put the
initialization into a static block with a try-catch inside the static block:
public class MyBean implements SessionBean {
static BeanX singleton = null;
static {
try {
BeanX singleton = ((BeanXHome)javax.rmi.PortableRemoteObject.narrow(
new InitialContext().lookup(path), BeanXHome.class)).create(parms)
} catch {
}
}
//... rest of bean methods
}
You would also need to implement the bean to deal with an uninitialized
reference if creating the bean fails in some way.
I'm not sure there would be a good use for a static reference to a bean,
though. I use a static data member to hold data used by all the bean
instances. What I do is in line with what the question that started this
thread wanted. I have some data in an LDAP directory. The data does not
change, but is used in the system. Rather than performing an LDAP search
everytime the bean needs the data (hundreds or thousands of times per day),
I
do the search when the bean class is loaded, and save the data into a static
member. This greatly reduces the number of LDAP searches.
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff EJB-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff EJB-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
Re: A question about singleton
I am a little bit confused by what you tried to do here. Why do you want your remote object to be a singleton? Should the container manager remote objects? ServiceLocator( a J2ee Pattern ) which is responsible for locating the bean's home or remote interface for the client should be singleton. But I do not see the point to make remote object singleton. Am I missing something here? -Original Message- From: Glyn Normington [mailto:[EMAIL PROTECTED]] Sent: Friday, June 08, 2001 9:17 AM To: [EMAIL PROTECTED] Subject: Re: A question about singleton Kevin Mukhar wrote: The classic pattern for the Singleton class uses a read-only static field to hold the Singleton reference, ... I suppose the initial expression for the static field would be like this: BeanX singleton = ((BeanXHome)javax.rmi.PortableRemoteObject.narrow( new InitialContext().lookup(path), BeanXHome.class)).create(parms) but where would this code would be placed. It's no good inside ejbCreate as ejbCreate is already running on a new instance rather than the singleton. So how could you implement the singleton portably? I would argue that the restriction against read/write statics applies to helper classes. I agree. CICS treats enterprise beans and their helper classes the same in this respect. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: newbie question
Hi, EJBHomes are cluster-aware stubs, hence will round-robin on each subsequent EJBHome.create() call. In fact, you SHOULD cache the EJBHome stub in your client (stick it in HttpSession or ServletContext for your JSP, and as a member var in your SSB); otherwise if you re-lookup the Home from JNDI for each request, the stub will not round-robining, but rather always hit the first server on its internal replica-aware list. To complicate the matter, WL does do collocation optimization. If your client and service reside in the same container, then you will not see round-robin-ing. All of this has been discussed extensively in newsgroups.bea.com. I would suggest looking there if u need more info. Gene -Original Message- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Tony Pelton Sent: Thursday, May 10, 2001 8:06 AM To: [EMAIL PROTECTED] Subject: newbie question Hi Folks, Being a fairly senior Java/Distributed System guy ... but being _very_ new to EJB ... and being under the gun to deliver iterations ... I need to blurt out a question that is likely obvious and documented ... and hope for an easy answer. Generically or specifically ... (specifically) TopLINK and Weblogic 5.1 (going to 6.0) (generically || specifically) In the case of a cluster of bean servers ... where all of your servers in the cluster have a deployment of all of your beans. As well, let's say the basic configuration is that a client (JSP), does a JNDI lookup (get home) and create() on a Stateless Session Bean (controller) which in turn does a JNDI lookup (get home) and create() on a Stateless Session Bean (manager) which in turn does JNDI lookup (get home) and create() on a specific type of Entity (the type that the given manager ... manages). JSP - Controller ManagerTypeA - EntityTypeA | - ManagerTypeB - EntityTypeB . . . (and so on ...) What I am trying to understand is some of the semantics of this under the covers. Does a home stub _imply_ that operations on the home stub e.g. create() are home'd to a given JVM in the cluster for the lifetime of that instance of that home interface ... or will create()s always be round robin to instances of JVM's in the cluster that have that bean deployed. Said a different way, in the case of a cluster where it is implied that the cluster is there to support load through replication ... where does the round-robin occur ... at lookup time of a given type of home ... or create time through the specific home stub instance. Are there any generic/specifc assumptions that can be made about optimizations with regard to create()s ... i.e. ... if a controller does a lookup/create() on a manager ... then it would _seem_ that it would be optimal to have the controller instance and the manager instance in the same JVM/process where possible ? These questions are born from some discussion around any efficiences that we might gain by having our controller and manager beans cache as attributes home stubs ... and potentially remote stubs. Some have even suggested that we encapsulate caching of stubs in the generic service in our infrastructure ... which personally makes me _very_ uncomfortable ... but I don't yet know why. Thanks for _any_ help based on your own real experiences ... or any pointers to information on actual implementation experience ... as oppossed ot stuff steeped in acadamiea. TIA, Tony --- Tony Pelton Developer tpelton at imany dot com http://www.i-many.com Hail to the King, Baby === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: newbie question regarding EJB security
Actually, you might want to consider an even more important question: In most application servers, the connections to a database are cached. Since the cache is set up in advance, it uses a common username and password which is shared by the entire server. The database, therefore, in most cases will not know which particular user it is working with at any one time. Now, not to scare you off, but if you think about it this will make sense. Since the application server is now in direct contact with the user, the app server is responsible for security to the data. The database only knows that it is talking to the applictaion server, and so it's security should center around what the application server can and cannot use. With this example, the findByPrimaryKey method can be coded to not return a valid code if the user is now allowed to see the data. Jonathan Baker Chris C wrote: Hi Folks, I got a security question regarding EJB as follows: === Environment === Let's say I have a table with two records as follows: 1. record A (owned by user A) and 2. record B (owned by user B) In addition, 1. database view is already setup for this table, so that user can only access his/her own record(s). 2. entity bean is created for the table. Question 1. if user A access record A via entity bean, does it mean the instance of record A would be created in EJB container? 2. is it possible for user B to access instance of record A via findByPrimaryKey? if yes, how can row level security be implemented? Thanks in advance !! P.S. I'm new to EJB, please be patient! Chris === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. -- Jonathan Baker Senior Architect eBusiness Division Sybase, Inc. [EMAIL PROTECTED] +1 510 922 0460 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff EJB-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: EJB question - Context.INITIAL_CONTEXT_FACTORY
From my limited experience with the J2EE RI server, you don't need to
pass a Properties object to the InitialContext constructor, just:
Context initial = new InitialContext();
If your J2EE RI server is on a different machine than your client, you
have to set an environment property before running your client. I think
this is a strange way of doing it instead of the documented way you were
describing.
Roslan
Brian Williams wrote:
I have a couple of EJBs. I used the Sun J2EE 1.2.1 deploytool to create a
.jar file. They run fine using Sun's j2ee...
Now I'm writing a Servlet in ATG Dynamo. I want these droplets/servlets to
call, via JNDI, remote methods in our EJBs. Ran into some problems using
ATG Dynamo's "runDarina" tool trying to install my j2ee ejb's within their
application server I know that in the Java code of my servlet I have to
have something like:
java.util.Properties env = new java.util.Properties ();
env.setProperty (Context.INITIAL_CONTEXT_FACTORY,
"...my ejb's context...");
env.setProperty (Context.PROVIDER_URL,
"my j2ee provider url");
Context initial = new InitialContext(env);
But how do I determine "...my ejb's context..." and "my j2ee provider
url"?? I think I can determine the latter from the output that I see when I
run "j2ee -verbose" :
J2EE server Listen Port: = 1049
Naming service started: :1050
Published the configuration object ...
Web service started: 9191
Web service started: 8000
Web service started: 7000
Loading
jar:/D:/j2sdkee1.2.1/repository/lu/applications/av983554636728Server.jar
/D:/j2sdkee1.2.1/repository/lu/applications/av983554636728Server.jar
Looking up authenticator...
Created Context:/SearchContextRoot
Binding name:`java:comp/env/ejb/Search`
J2EE server startup complete.
But how do I determine my EJB's INITIAL_CONTEXT_FACTORY?? Now in my EJB I
have this:
public void ejbCreate() {
}
Do I need to, in order for the Servlet to get my EJB's
INITIAL_CONTEXT_FACTORY, change it to something like:
public void ejbCreate()
throws CreateException, RemoteException {
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,
"com.blah.jndi.BlahContextFactory");
try{
ctx = new InitialContext(env);
}catch(Exception e) {
System.out.println("create exception: "+e);
}
}
and then in my servlet code put:
env.setProperty (Context.INITIAL_CONTEXT_FACTORY,
"com.blah.jndi.BlahContextFactory");
???
Or can I set the INITIAL_CONTEXT_FACTORY name using the Sun J2EE deploytool?
Thanks,
/ Brian
_
Get your FREE download of MSN Explorer at http://explorer.msn.com
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
Re: servlet Question...
This is EJB interest and not SERVLET interest. Amit Gupta wrote: Since you guys are good in servlet, I am daring to ask this Question. Is there any method defined in servlet API to find out the servlet container's log file. I do not want to hard code the name of the file in my code because I might be running the same servlet within different servlet containers. Amit Gupta === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: servlet Question...
Sven, Man, you don't have to be that rude just because the guy didn't send the question to the right list !! :o) Amit, as far as I know the log method of the servlet API doesn't let you specify the name of the log file, as this is server dependent. If you need it because you want to access it from another point in your application maybe you should use another way of communication. Regards Jose P.S: By the way, next time look for a more appropiate list... you may see the complete list at http://archives.java.sun.com/archives/ ;o) Sven van t Veer wrote: This is EJB interest and not SERVLET interest. Amit Gupta wrote: Since you guys are good in servlet, I am daring to ask this Question. Is there any method defined in servlet API to find out the servlet container's log file. I do not want to hard code the name of the file in my code because I might be running the same servlet within different servlet containers. Amit Gupta === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: security question (correction)
Are you looking for container support for authentication/authorization using JAAS or EJB support for authentication/authorization using JAAS ? Thanks, Anthony Nadalin ___ mailto:[EMAIL PROTECTED] John Harby [EMAIL PROTECTED]@JAVA.SUN.COM on 01/24/2001 09:47:44 AM Please respond to A mailing list for Enterprise JavaBeans development [EMAIL PROTECTED] Sent by: A mailing list for Enterprise JavaBeans development [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: security question (correction) Sorry about this - Where I typed "JMS" below, it should read "JAAS" "We are in a situation where we can't use role-based security, we must use permission-based. The reason being that the domain specifies very dynamic permission assignments and the number of roles generated by this scenario would be huge. Has anyone dealt with this sort of situation before? Someone in our team had mentioned the possibility of using JMS, has anyone tried this? " _ Get your FREE download of MSN Explorer at http://explorer.msn.com === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: Newbie Question
go to this site-- http://www.execpc.com/~gopalan/java/ejb.html cheers srinivas - Original Message - From: Ripan Bansal [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 18, 2001 12:18 PM Subject: Newbie Question I am new to all this stuff. I have just started learning EJB due to my project requirements. I have a very basic question regarding the design of the EJB architecture. I want to know why do we need to have EJBHome and EJBObjects? Why can't we do away with just one object implemented by the proprietry Application server. Suggest me some good material to start with. Any pointers in this regard are highly appreciated. Thanks Ripan === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: Newbie Question
Hi, EJBObjects: The client does not invoke a method directly on the actual bean instance. Instead, the call is intercepted by the container and = delegated to the bean instance. Reasons: 1. The EJB is not network enabled and the container handles the networking for it (by wrapping the bean in a network enabled object). 2. The Container can implement Security, Pooling, Transaction Management logic to the request. 3. The Container can track all the methods that were called on the bean, load balance etc. The EJBObject is a (surrogate) object that knows about management, security etc. It performs the logic that the container requires before a method is serviced by a bean class instance. All EJBObjects have container specific code inside them. EJBHome: The client cannot invoke an EJBObject directly as they are on separate machines. Alos the EJB Specification espouses location transparency - = the client should not be aware where the EJBObject exists. To acquire an EJBObject, the client requests the EJBObjectFactory for an EJBObject. This factory - which is responsible for creating and = destroying EJBObjects, is called Home Object. Guess this will shed some light. Nitin - Original Message - From: "Ripan Bansal" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 18, 2001 12:18 PM Subject: Newbie Question I am new to all this stuff. I have just started learning EJB due to my project requirements. I have a very basic question regarding the design of the EJB architecture. I want to know why do we need to have EJBHome and EJBObjects? Why can't we do away with just one object implemented by the proprietry Application server. Suggest me some good material to start with. Any pointers in this regard are highly appreciated. Thanks Ripan === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: Newbie Question
refer the book by EDRoman -Original Message- From: Srinivas K. R. [mailto:[EMAIL PROTECTED]] Sent: Friday, January 19, 2001 1:58 AM To: [EMAIL PROTECTED] Subject: Re: Newbie Question go to this site-- http://www.execpc.com/~gopalan/java/ejb.html cheers srinivas - Original Message - From: Ripan Bansal [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 18, 2001 12:18 PM Subject: Newbie Question I am new to all this stuff. I have just started learning EJB due to my project requirements. I have a very basic question regarding the design of the EJB architecture. I want to know why do we need to have EJBHome and EJBObjects? Why can't we do away with just one object implemented by the proprietry Application server. Suggest me some good material to start with. Any pointers in this regard are highly appreciated. Thanks Ripan === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: Newbie Question
My doubts are inline -Original Message- From: Nitin Goyal [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 18, 2001 1:59 PM To: [EMAIL PROTECTED] Subject: Re: Newbie Question Hi, EJBObjects: The client does not invoke a method directly on the actual bean instance. Instead, the call is intercepted by the container and = delegated to the bean instance. Reasons: 1. The EJB is not network enabled and the container handles the networking for it (by wrapping the bean in a network enabled object). 2. The Container can implement Security, Pooling, Transaction Management logic to the request. 3. The Container can track all the methods that were called on the bean, load balance etc. The EJBObject is a (surrogate) object that knows about management, security etc. It performs the logic that the container requires before a method is serviced by a bean class instance. All EJBObjects have container specific code inside them. //Ripan //This part is okay. EJBHome: The client cannot invoke an EJBObject directly as they are on separate machines. //I am not clear about this thing. Is there always something in between the EJBObject and the client. As fas as i know EJBObject is network enabled. It is directly accessed from the client machine.(Ofcourse with hidden stub and skeleton) Alos the EJB Specification espouses location transparency - = the client should not be aware where the EJBObject exists. To acquire an EJBObject, the client requests the EJBObjectFactory for an EJBObject. This factory - which is responsible for creating and = destroying EJBObjects, is called Home Object. //Yes for promoting location trasparency, the JNDI lookup is used to get the ref to the EJBHome. Instead of looking for EJBHome, lookup can be done for EJBObject. I am still not clear about the need of the EJBHome. Guess this will shed some light. Nitin - Original Message - From: "Ripan Bansal" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 18, 2001 12:18 PM Subject: Newbie Question I am new to all this stuff. I have just started learning EJB due to my project requirements. I have a very basic question regarding the design of the EJB architecture. I want to know why do we need to have EJBHome and EJBObjects? Why can't we do away with just one object implemented by the proprietry Application server. Suggest me some good material to start with. Any pointers in this regard are highly appreciated. Thanks Ripan === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: Newbie Question
what exactly is EJBObject and how is it differnet from bean instance. are container and ejb server different? -Original Message- From: Srinivas K. R. [mailto:[EMAIL PROTECTED]] Sent: Friday, January 19, 2001 1:58 AM To: [EMAIL PROTECTED] Subject: Re: Newbie Question go to this site-- http://www.execpc.com/~gopalan/java/ejb.html cheers srinivas - Original Message - From: Ripan Bansal [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 18, 2001 12:18 PM Subject: Newbie Question I am new to all this stuff. I have just started learning EJB due to my project requirements. I have a very basic question regarding the design of the EJB architecture. I want to know why do we need to have EJBHome and EJBObjects? Why can't we do away with just one object implemented by the proprietry Application server. Suggest me some good material to start with. Any pointers in this regard are highly appreciated. Thanks Ripan === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: Newbie Question
Hi, Please see the mail from Nitin Goyal, you must have got it few moments earlier. EJBObjects is a object that sits between the bean object and the client. All the interactions between the client and bean object are through this EJBObject. Since, EJBObject sits between the two it is capable of performing some intelligent work like managing transactions, security etc which otherwise you have to take care. This is just a programming model or architecture. There is no technical reason that only this solution is possible. You could have coded the entire network enabled bean object of your own without ever worrying about the container or having EJBObject in between. But it is always advisable to use the existing infrastructure and concentrate on the business logic rather than re-inventing the wheel and writing the system level services by ourself. EJBObject and bean object are completely different, bean is something which you code as a developer and you are responsible for its code and the work responsibilites. I mean to say that bean has a specific objective to achieve like business logic. But the business logic object requires some services for its safe operation and these services are provided by the container and you as a programmer take advantage of these services by coding according to the specification advocated by the particular container. Container accomplish this by having a EJBObject for each and every bean object deployed with it. EJBObject is implemented by the container itself and it is completely container dependent. For practical purposes there is no difference between the container and the ejb sever or application server. But Sun says that it will define an interface between the container and the server as well during the course of time like interface between the container and the bean coded by the programmer. EJB is a interface between the container and the bean so that the bean can be deployed accross multiple containers without changing the code. This makes it container independent or atleast theoratically allows application server to be changed. If you still have doubts please feel free to contact me. Ripan -Original Message- From: Gopi Krishna [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 18, 2001 2:41 PM To: [EMAIL PROTECTED] Subject: Re: Newbie Question what exactly is EJBObject and how is it differnet from bean instance. are container and ejb server different? -Original Message- From: Srinivas K. R. [mailto:[EMAIL PROTECTED]] Sent: Friday, January 19, 2001 1:58 AM To: [EMAIL PROTECTED] Subject: Re: Newbie Question go to this site-- http://www.execpc.com/~gopalan/java/ejb.html cheers srinivas - Original Message - From: Ripan Bansal [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 18, 2001 12:18 PM Subject: Newbie Question I am new to all this stuff. I have just started learning EJB due to my project requirements. I have a very basic question regarding the design of the EJB architecture. I want to know why do we need to have EJBHome and EJBObjects? Why can't we do away with just one object implemented by the proprietry Application server. Suggest me some good material to start with. Any pointers in this regard are highly appreciated. Thanks Ripan === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: Newbie Question
Hi, An EJBObject is network enabled and callable from other JVMs as it implements the Remote interface (javax.ejb.EJBObject extends java.rmi.Remote). file://Yes for promoting location trasparency, the JNDI lookup is used to get the ref to the EJBHome. Instead of looking for EJBHome, lookup can be done for EJBObject. How does a client acquire a reference to the EJBObject if they are residing on separate machines? How will a client find existing EJBObjects? How will the EJBObjects will be created and removed? Home Interfaces simply define the methods for creating/destroying/finding EJBObjects. The containter's home object IMPLEMENTS your home interface. Thus the steps are: 1. Client request for a new EJBObject. 2. The HomeObject, which implements the Home Interface, intercepts this call and creates an EJBObject. 3. The HomeObject returns the EJBObject ref to the client. Still out in the cold? :-) Regards, Nitin - Original Message - From: "Ripan Bansal" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 18, 2001 2:36 PM Subject: Re: Newbie Question My doubts are inline -Original Message- From: Nitin Goyal [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 18, 2001 1:59 PM To: [EMAIL PROTECTED] Subject: Re: Newbie Question Hi, EJBObjects: The client does not invoke a method directly on the actual bean instance. Instead, the call is intercepted by the container and = delegated to the bean instance. Reasons: 1. The EJB is not network enabled and the container handles the networking for it (by wrapping the bean in a network enabled object). 2. The Container can implement Security, Pooling, Transaction Management logic to the request. 3. The Container can track all the methods that were called on the bean, load balance etc. The EJBObject is a (surrogate) object that knows about management, security etc. It performs the logic that the container requires before a method is serviced by a bean class instance. All EJBObjects have container specific code inside them. file://Ripan file://This part is okay. EJBHome: The client cannot invoke an EJBObject directly as they are on separate machines. file://I am not clear about this thing. Is there always something in between the EJBObject and the client. As fas as i know EJBObject is network enabled. It is directly accessed from the client machine.(Ofcourse with hidden stub and skeleton) Alos the EJB Specification espouses location transparency - = the client should not be aware where the EJBObject exists. To acquire an EJBObject, the client requests the EJBObjectFactory for an EJBObject. This factory - which is responsible for creating and = destroying EJBObjects, is called Home Object. file://Yes for promoting location trasparency, the JNDI lookup is used to get the ref to the EJBHome. Instead of looking for EJBHome, lookup can be done for EJBObject. I am still not clear about the need of the EJBHome. Guess this will shed some light. Nitin - Original Message - From: "Ripan Bansal" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 18, 2001 12:18 PM Subject: Newbie Question I am new to all this stuff. I have just started learning EJB due to my project requirements. I have a very basic question regarding the design of the EJB architecture. I want to know why do we need to have EJBHome and EJBObjects? Why can't we do away with just one object implemented by the proprietry Application server. Suggest me some good material to start with. Any pointers in this regard are highly appreciated. Thanks Ripan === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: Newbie Question
Hi, See inline -Original Message- From: Nitin Goyal [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 18, 2001 3:54 PM To: [EMAIL PROTECTED] Subject: Re: Newbie Question Hi, An EJBObject is network enabled and callable from other JVMs as it implements the Remote interface (javax.ejb.EJBObject extends java.rmi.Remote). file://Yes for promoting location trasparency, the JNDI lookup is used to get the ref to the EJBHome. Instead of looking for EJBHome, lookup can be done for EJBObject. How does a client acquire a reference to the EJBObject if they are residing on separate machines? //Even EJBHome object resides in the different machine. How will a client find existing EJBObjects? //A client can find the existing object using EJBObject only. It will ask the EJBObject for another object and if it exists it will return the ref to the object similar to what EJBHome is doing. How will the EJBObjects will be created and removed? //Object will be created when the lookup is done and will be removed like wise. Home Interfaces simply define the methods for creating/destroying/finding EJBObjects. The containter's home object IMPLEMENTS your home interface. //I never said that home object does not implement the home interface why can't EJBObject implement the home interface also providing features for removing and finding other EJB objects. Thus the steps are: 1. Client request for a new EJBObject. 2. The HomeObject, which implements the Home Interface, intercepts this call and creates an EJBObject. 3. The HomeObject returns the EJBObject ref to the client. //These steps are valid for your way of viewing the things. Still out in the cold? :-) //Yes Regards, Nitin - Original Message - From: "Ripan Bansal" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 18, 2001 2:36 PM Subject: Re: Newbie Question My doubts are inline -Original Message- From: Nitin Goyal [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 18, 2001 1:59 PM To: [EMAIL PROTECTED] Subject: Re: Newbie Question Hi, EJBObjects: The client does not invoke a method directly on the actual bean instance. Instead, the call is intercepted by the container and = delegated to the bean instance. Reasons: 1. The EJB is not network enabled and the container handles the networking for it (by wrapping the bean in a network enabled object). 2. The Container can implement Security, Pooling, Transaction Management logic to the request. 3. The Container can track all the methods that were called on the bean, load balance etc. The EJBObject is a (surrogate) object that knows about management, security etc. It performs the logic that the container requires before a method is serviced by a bean class instance. All EJBObjects have container specific code inside them. file://Ripan file://This part is okay. EJBHome: The client cannot invoke an EJBObject directly as they are on separate machines. file://I am not clear about this thing. Is there always something in between the EJBObject and the client. As fas as i know EJBObject is network enabled. It is directly accessed from the client machine.(Ofcourse with hidden stub and skeleton) Alos the EJB Specification espouses location transparency - = the client should not be aware where the EJBObject exists. To acquire an EJBObject, the client requests the EJBObjectFactory for an EJBObject. This factory - which is responsible for creating and = destroying EJBObjects, is called Home Object. file://Yes for promoting location trasparency, the JNDI lookup is used to get the ref to the EJBHome. Instead of looking for EJBHome, lookup can be done for EJBObject. I am still not clear about the need of the EJBHome. Guess this will shed some light. Nitin - Original Message - From: "Ripan Bansal" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 18, 2001 12:18 PM Subject: Newbie Question I am new to all this stuff. I have just started learning EJB due to my project requirements. I have a very basic question regarding the design of the EJB architecture. I want to know why do we need to have EJBHome and EJBObjects? Why can't we do away with just one object implemented by the proprietry Application server. Suggest me some good material to start with. Any pointers in this regard are highly appreciated. Thanks Ripan === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send e
Re: Newbie Question
Hi, The EJB spec v2.0 can probably answer all your questions if you have the patience to read it. I am learning it too. I got an eval copy of weblogic and if you have the patience you can convert it into a full-fledged app server with clustering, SSL and ejb deployment etc. enabled. It took me half hour to do this.During this process you can plow through the source code too and probably learn everything about EJB, JTA, JMS etc. JBoss sources will help too. Probably the architecture pattern of EJB will help too. Similarly if you decompile all the classes that the container generates you will know how weblogic honors the container contract. In the process you can write your container also. You can also learn how they have implemented the RMI patterns behing EJB. I know I have to stop here. bye, Mohan Ripan Bansal wrote: I am new to all this stuff. I have just started learning EJB due to my project requirements. I have a very basic question regarding the design of the EJB architecture. I want to know why do we need to have EJBHome and EJBObjects? Why can't we do away with just one object implemented by the proprietry Application server. Suggest me some good material to start with. Any pointers in this regard are highly appreciated. Thanks Ripan === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: basic question
The following is my batch file in unix:
Which complier all you source file and packed into jar file.
you can use it like this:
BB MyPackage MyJarFile
Chalres Guo
BB.sh
JAVA_HOME=${JAVA_HOME:-"/opt/java"}
WL_HOME=${WL_HOME:-"/app/project/weblogic"}
BIN=/app/project/weblogic/myserver/serverclasses
EJB=/app/project/ejbs
mkdir -p build build/META-INF
cp -f *.xml build/META-INF
echo now to build class
javac -d build *.java
echo now to build jar
java weblogic.ejbc build/$2.jar $EJB/$2.jar
-Original Message-
From: saisuraj chengalvala [SMTP:[EMAIL PROTECTED]]
Sent: Saturday, December 09, 2000 2:32 PM
To: [EMAIL PROTECTED]
Subject: basic question
I am just trying to run an ejb example on Weblogic.Is there any
provision to compile all the xxx.java files through weblogic.Pl let me
know.Or shall we need to compile the individual files through java
compiler only
http://mail.indiainfo.com
First you had 10MB of free mail space.
Now you can send mails in your own language !!!
==
=
To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
Re: [JDBC Question]
Hi Chua!
It is perfectly legal to use executeUpdate() method to check how many rows
have been affected by the query. You typically use execute() method to return
a ResultSet and execute() to return boolean value.
I hope this clarifies your doubt.
MKumaresan
Jerson Chua [EMAIL PROTECTED] wrote:
Hello EJB Gurus...
Sorry for asking this off topic question here.
I have a very simple question. I'm trying to insert a row to a table using
JDBC.
Is it logical or does it make sense to check if the executeUpdate returns
the value 1? To make sure that the row is indeed inserted to the table.
e.g.
Does this make sense?
if (pStmt.executeUpdate() != 1) {
//throw Exception
}
or
pStmt.executeUpdate() is enough.
What's your opinion?
Jerson Chua, SCJP2
Java Applications Engineer
CyberJ Resources, Inc.
1408/1409 Jollibee Plaza, Emerald Avenue
Ortigas Centre, Pasig City
Philippines
T: 632.638.61.38
F: 632.638.61.39
Email: [EMAIL PROTECTED]
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
Get free email and a permanent address at http://www.netaddress.com/?N=1
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
Re: [JDBC Question]
Thanks for your reply...
But my question is do I still need to check if the executeUpdate returns the
value 1 cause I think if the executeUpdate fails, it would throw an
exception. I just want to know if there's a possibility that the row is not
inserted and no exception is thrown.
Jerson
-Original Message-
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Kumaresan Manickavasagam
Sent: Tuesday, November 07, 2000 3:01 AM
To: [EMAIL PROTECTED]
Subject: Re: [JDBC Question]
Hi Chua!
It is perfectly legal to use executeUpdate() method to check how many rows
have been affected by the query. You typically use execute() method to
return
a ResultSet and execute() to return boolean value.
I hope this clarifies your doubt.
MKumaresan
Jerson Chua [EMAIL PROTECTED] wrote:
Hello EJB Gurus...
Sorry for asking this off topic question here.
I have a very simple question. I'm trying to insert a row to a table using
JDBC.
Is it logical or does it make sense to check if the executeUpdate returns
the value 1? To make sure that the row is indeed inserted to the table.
e.g.
Does this make sense?
if (pStmt.executeUpdate() != 1) {
//throw Exception
}
or
pStmt.executeUpdate() is enough.
What's your opinion?
Jerson Chua, SCJP2
Java Applications Engineer
CyberJ Resources, Inc.
1408/1409 Jollibee Plaza, Emerald Avenue
Ortigas Centre, Pasig City
Philippines
T: 632.638.61.38
F: 632.638.61.39
Email: [EMAIL PROTECTED]
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
Get free email and a permanent address at http://www.netaddress.com/?N=1
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
. to [EMAIL PROTECTED] and include in the body of the message "help".
.
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
Re: [JDBC Question]
Hi,
Yes, for example if you use a stored procedure and an
error is trapped in there. THen from the calling java
program, it will appear that all went well at the
server side where the stored procedure was executed.
ron
--- Jerson Chua [EMAIL PROTECTED] wrote:
Thanks for your reply...
But my question is do I still need to check if the
executeUpdate returns the
value 1 cause I think if the executeUpdate fails, it
would throw an
exception. I just want to know if there's a
possibility that the row is not
inserted and no exception is thrown.
Jerson
-Original Message-
From: A mailing list for Enterprise JavaBeans
development
[mailto:[EMAIL PROTECTED]]On Behalf Of
Kumaresan Manickavasagam
Sent: Tuesday, November 07, 2000 3:01 AM
To: [EMAIL PROTECTED]
Subject: Re: [JDBC Question]
Hi Chua!
It is perfectly legal to use executeUpdate() method
to check how many rows
have been affected by the query. You typically use
execute() method to
return
a ResultSet and execute() to return boolean value.
I hope this clarifies your doubt.
MKumaresan
Jerson Chua [EMAIL PROTECTED] wrote:
Hello EJB Gurus...
Sorry for asking this off topic question here.
I have a very simple question. I'm trying to
insert a row to a table using
JDBC.
Is it logical or does it make sense to check if
the executeUpdate returns
the value 1? To make sure that the row is indeed
inserted to the table.
e.g.
Does this make sense?
if (pStmt.executeUpdate() != 1) {
//throw Exception
}
or
pStmt.executeUpdate() is enough.
What's your opinion?
Jerson Chua, SCJP2
Java Applications Engineer
CyberJ Resources, Inc.
1408/1409 Jollibee Plaza, Emerald Avenue
Ortigas Centre, Pasig City
Philippines
T: 632.638.61.38
F: 632.638.61.39
Email: [EMAIL PROTECTED]
===
To unsubscribe, send email to
[EMAIL PROTECTED] and include in the
body
of the message "signoff EJB-INTEREST". For
general help, send email to
[EMAIL PROTECTED] and include in the body of
the message "help".
Get free email and a permanent address at
http://www.netaddress.com/?N=1
===
To unsubscribe, send email to [EMAIL PROTECTED]
and include in the body
of the message "signoff EJB-INTEREST". For general
help, send email to
[EMAIL PROTECTED] and include in the body of the
message "help".
. to [EMAIL PROTECTED] and include in the body
of the message "help".
.
===
To unsubscribe, send email to [EMAIL PROTECTED]
and include in the body
of the message "signoff EJB-INTEREST". For general
help, send email to
[EMAIL PROTECTED] and include in the body of the
message "help".
__
Do You Yahoo!?
Thousands of Stores. Millions of Products. All in one Place.
http://shopping.yahoo.com/
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
Re: [JDBC Question]
Thanks to everyone who replied.
Jerson
-Original Message-
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Ron Chan
Sent: Tuesday, November 07, 2000 11:19 AM
To: [EMAIL PROTECTED]
Subject: Re: [JDBC Question]
Hi,
Yes, for example if you use a stored procedure and an
error is trapped in there. THen from the calling java
program, it will appear that all went well at the
server side where the stored procedure was executed.
ron
--- Jerson Chua [EMAIL PROTECTED] wrote:
Thanks for your reply...
But my question is do I still need to check if the
executeUpdate returns the
value 1 cause I think if the executeUpdate fails, it
would throw an
exception. I just want to know if there's a
possibility that the row is not
inserted and no exception is thrown.
Jerson
-Original Message-
From: A mailing list for Enterprise JavaBeans
development
[mailto:[EMAIL PROTECTED]]On Behalf Of
Kumaresan Manickavasagam
Sent: Tuesday, November 07, 2000 3:01 AM
To: [EMAIL PROTECTED]
Subject: Re: [JDBC Question]
Hi Chua!
It is perfectly legal to use executeUpdate() method
to check how many rows
have been affected by the query. You typically use
execute() method to
return
a ResultSet and execute() to return boolean value.
I hope this clarifies your doubt.
MKumaresan
Jerson Chua [EMAIL PROTECTED] wrote:
Hello EJB Gurus...
Sorry for asking this off topic question here.
I have a very simple question. I'm trying to
insert a row to a table using
JDBC.
Is it logical or does it make sense to check if
the executeUpdate returns
the value 1? To make sure that the row is indeed
inserted to the table.
e.g.
Does this make sense?
if (pStmt.executeUpdate() != 1) {
//throw Exception
}
or
pStmt.executeUpdate() is enough.
What's your opinion?
Jerson Chua, SCJP2
Java Applications Engineer
CyberJ Resources, Inc.
1408/1409 Jollibee Plaza, Emerald Avenue
Ortigas Centre, Pasig City
Philippines
T: 632.638.61.38
F: 632.638.61.39
Email: [EMAIL PROTECTED]
===
To unsubscribe, send email to
[EMAIL PROTECTED] and include in the
body
of the message "signoff EJB-INTEREST". For
general help, send email to
[EMAIL PROTECTED] and include in the body of
the message "help".
Get free email and a permanent address at
http://www.netaddress.com/?N=1
===
To unsubscribe, send email to [EMAIL PROTECTED]
and include in the body
of the message "signoff EJB-INTEREST". For general
help, send email to
[EMAIL PROTECTED] and include in the body of the
message "help".
. to [EMAIL PROTECTED] and include in the body
of the message "help".
.
===
To unsubscribe, send email to [EMAIL PROTECTED]
and include in the body
of the message "signoff EJB-INTEREST". For general
help, send email to
[EMAIL PROTECTED] and include in the body of the
message "help".
__
Do You Yahoo!?
Thousands of Stores. Millions of Products. All in one Place.
http://shopping.yahoo.com/
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
. "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help". .
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
Re: Design Question...Modelling Products and Related Products
Hello Brendan,
So given product A and product B, I need to model a relationship or "link"
between A and B. My first impression was that the "link" was a dependant
object. So if I create A and "link" to B, the the "link" is a dependant
object of A. This implies that A is responsible for the "link" (i.e. it's
creation, deletion etc etc) so that if A is removed, so too is the "link".
But what happens in the event that B is removed? Surely the "link" from A
to
B should also be removed, since it's not longer valid? But B can't remove
the "link", because the "link" was made by A...it would have to ask A to
remove it, and since there's potentially a lot of "A"s linking to B, this
could mean a lot of overhead.
I would suggest a separate Session Bean called RelationshipService or
ProductRelationService. It could have an interface like that
public interface ProductRelationService ... {
public addRelation(ProductPK p1, ProductPK p2);
// returns collections of PKs
public Collection getRelationsOf(ProductPK p);
public void removeRelationsOf(ProductPK p);
public void removeRelation(ProductPK p1, ProductPK p2);
...
}
regards,
--
[EMAIL PROTECTED]
MATHEMA Software GmbH
Nägelsbachstraße 25 b
91052 E r l a n g e n
D e u t s c h l a n d
Tel +49(0)9131/8903-0
Fax +49(0)9131/8903-55
http://www.mathema.de
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
Re: Newbie question: How are keys generated?
Hi, Good call! Sorry about my blunder; EntityContext has client-contextual info, hence makes sense to be created only when the client requests for a specific bean info! I guess I always associate the PrimaryKey with the EntityContext and not the EJBObject because all the EJB books I read tell me when I'm in a bean instance and need the PK, call getEntityContext().getPrimaryKey(). Although getEJBObject().getPrimaryKey() would return the exact same object, I think this invocation is more indicative of exactly where the PK resides. Gene -Original Message- From: A mailing list for Enterprise JavaBeans development To: [EMAIL PROTECTED] Sent: 8/29/00 11:18 PM Subject: Re: Newbie question: How are keys generated? When you ejbCreate a new bean, you create the PK object in this method and pass it out in the return; the server container the takes over and does the "setting". This implementation is vendor-specific, but in general the container would 1) create an EntityContext that refers to the pk 2) create an EJBObject that's somehow affiliated to this EntityContext 3) return the EJBObject to you (from EJBHome.create) A minor clarification for step 1 - the entity context will not get created as a result of an ejbCreate. The entity context gets created when the container creates entity bean instances. When an entity bean instance is associated with an EJBObject, the EntityContext would get hold of this EJBObject and the primary key. so the steps would be 1. create an EJBObject and associate the primary key with this EJBObject 2. At a later time when an entity bean instance is required by this EJBObject, the container will get a free bean instance and associate the bean instance and its entity context with the EJBObject -saurabh === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: Newbie question: How are keys generated?
Hi Neil, Where and how are the keys generated? The answer to your question is really 2-layered. On the database side, the primary key generation is based on the db implementation. For a SQL table with a column declared as the PK, this sequence is generated and maintained by the database. And if you simply map a row in this table to an entity bean, in most cases your EJB PK would be a wrapper (or custom class) to this database PK. However, if you require a more complex EJB PK, e.g. one that maps to more than one column in your db table, then you would define a PK class that holds references to these two values. Hence you "generate" your PK from the two values you decide to insert into your db table. So technically, in either case, YOU are responsible for creating the PK object from info you obtain either from the db or elsewhere (static counter, GUID, Unique PK generating algorithm, etc..) But, what I dont know the PK ever gets set. When you ejbCreate a new bean, you create the PK object in this method and pass it out in the return; the server container the takes over and does the "setting". This implementation is vendor-specific, but in general the container would 1) create an EntityContext that refers to the pk 2) create an EJBObject that's somehow affiliated to this EntityContext 3) return the EJBObject to you (from EJBHome.create) You now have a remote EJB reference from which you can retrieve the primary key, as well as bean info. Hope that helps a little! Gene Chuang Teach the world... Join Kiko! http://www.kiko.com/profile/join.jsp?refcode=TAF-gchuang -Original Message- From: A mailing list for Enterprise JavaBeans development To: [EMAIL PROTECTED] Sent: 8/29/00 9:27 PM Subject: Newbie question: How are keys generated? Hello: I am new to EJB and I am sure that it shows, but I have a very simple question: Where and how are the keys generated? I have read everythign I can find and all the docs and books talk about the higher level stuff, but this question still causes me to wonder. For example, I am trying to model an Employee that has a Name. So, I created a database table: CREATE TABLE Employee ( Employee_PK INTEGER NOT NULL, Name VARCHAR NOT NULL ) I think I understand how to write the EJB, do all the BMP SQL code, etc., etc. But, what I dont know is how the PK ever gets set. Can anyone clear this up for me? Thanks, Neil. -- Neil Aggarwal, President CEO JAMM Consulting, Inc. (http://www.JAMMConsulting.com) Custom Programming in Java, C, C++, perl, HTML, CGI === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: Newbie question: How are keys generated?
When you ejbCreate a new bean, you create the PK object in this method and pass it out in the return; the server container the takes over and does the "setting". This implementation is vendor-specific, but in general the container would 1) create an EntityContext that refers to the pk 2) create an EJBObject that's somehow affiliated to this EntityContext 3) return the EJBObject to you (from EJBHome.create) A minor clarification for step 1 - the entity context will not get created as a result of an ejbCreate. The entity context gets created when the container creates entity bean instances. When an entity bean instance is associated with an EJBObject, the EntityContext would get hold of this EJBObject and the primary key. so the steps would be 1. create an EJBObject and associate the primary key with this EJBObject 2. At a later time when an entity bean instance is required by this EJBObject, the container will get a free bean instance and associate the bean instance and its entity context with the EJBObject -saurabh === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: newbie question
J2EE Reference implementation : How to get and set up @ http://developer.java.sun.com/developer/onlineTraining/EJBIntro/exercises/Se tupJ2EERI/index.html -Original Message- From: Jarzan [mailto:[EMAIL PROTECTED]] Sent: Saturday, July 29, 2000 2:28 AM To: [EMAIL PROTECTED] Subject: newbie question I am new in this EJB world and I want to get an application server to test my ejbs. Is there any reference implementation available on JavaSoft? What about jsdkee? Is it fine for ejb testing and what database does it support? == = To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: Newbie question - Problem Deploying
Well I think it is safe to say that all EJB servers are case-sensitive about
Java method names ;-)
the method is :
public int hashCode()
http://java.sun.com/products/jdk/1.2/docs/api/java/lang/Object.html#hashCode
()
cheers,
jmp
-Original Message-
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Greg H.
Sent: Thursday, July 27, 2000 2:05 PM
To: [EMAIL PROTECTED]
Subject: Newbie question - Problem Deploying
Hello all,
While I know that many get upset postings that relate to
particular products, my problem may or may not product specific.
I am trying to deploy an entity bean and keep getting the same
error(Weblogic).
Namely, In EJB Users, the primary key class must implement the
method public int hashcode()
The problem is that I cannot figure out how to resolve the issue.
Below is my UsersPK file. I assume that is what is giving me
the error. Any and all help will be greatly appreciated.
Thanks,
Greg
package untitled2;
public class UsersPK implements java.io.Serializable {
public int id;
public int hashcode(){
return id;
}
public boolean equals(Object obj) {
if(obj instanceof UsersPK) {
return (id == ((UsersPK)obj).id);
}
return false;
}
public UsersPK(){}
}
==
=
To unsubscribe, send email to [EMAIL PROTECTED] and include
in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
Re: IDE question for developing EJBs
Well, if it comes down to between VCafe and JBuilder, I would say it is a no contest. JBuilder it is. Of the big three, VCafe, JBuilder and VAJ, only JBuilder has a runtime which is 1.1 compliant as IAS is. VCafe is supposed to, but it is beset with problems. When it comes to tight integration between app server and IDE, probably VAJ is the best of the lot. (i.e.) there is no such thing as hot deploy. Once deployed, you go change the code and save and bang, you are ready to go. In fact, I frequently keep my test client (generated from VAJ) open and go fix my bug/change in the code, save and re-test with all of them running. VAJ vs JBuilder is also interesting with respect to team development. I find VAJ's repository based approach better for large teams and it's cross-referencing etc.. has been great and its integration with TeamServer (envoy) good for large teams. Thus, if 1.1 compliance is important, go JBuilder. But, if you want a generic EJB tool, eval both JBuilder and VAJ and depending on your target app server you will quickly work out which suits you best. It will also be a matter of personal taste as you will find VAJ different to the regular file based IDE approach. I wouldn't touch VCafe Ent with a barge pole. I found it weak and most irritating, it crashed so often. But, if your target app server is WebLogic, I expect VCafe with BEA's influence in it now, will come up to speed. Eventually. PS: While you are at it, look into "vi/vim" as an editor of choice. Emacs ^%$$#@!! ;-) -- Aravind -Original Message- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of kishore puvvada Sent: Friday, 26 May 2000 02:29 To: [EMAIL PROTECTED] Subject: IDE question for developing EJBs Hi, This is not a direct EJB question, please pardon me. We are wrestling with the decision in the past couple of days whether we use VCafe ent or JB ent editions. There is no doubt we need an IDE :-), as opposed to using an emacs editor. The choice needs to address a wide range of people with different programming expertise in Java/EJB. We found out that VCafe ent is not EJB 1.1 compliant, whereas JB is. And enumerated the following reasons why JB is better to use: The EJB interface wizard differences - create methods returning void vs primary-key object. The ability to do hot-deploy through hooks to your app server. Here there is the main problem we are facing. This hook does not seem to work properly from VCafe ent to do hot-deply into WL 5.1 server. Which is 1.1 compliant. Can you help me understand the issues better? I searched in the archives and on the internet in general, but am unable to get more info. thanks, Kishore. = cheers, kp@yahoo __ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/ == = To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: Transaction question
Tom,
By virtue of deploying both beans as TX_REQUIRED, the behavior you desire
(e.g. single atomic unit of work) is automatically provided by the EJB
server/container.
-Chris.
-Original Message-
From: Tom Preston [SMTP:[EMAIL PROTECTED]]
Sent: Thursday, May 18, 2000 12:53 PM
To: [EMAIL PROTECTED]
Subject: Transaction question
I have a session bean talking to an entity bean both are TX_REQUIRED. I
have a method in the
session bean that calls create and multiple set methods in the entity
bean. It does somethhing like this:
public void mySessionMethod(Vector record) {
Contextctx = Utils.getServerInitialContext();
Raw_dataHome RDH = (Raw_dataHome) ctx.lookup("Raw_dataHome");
Raw_data RD = RDH.create(new Integer(dataProviderId), batchTime);
RD.setShipname((String)record.elementAt(0));
RD.setShort_desc((String)record.elementAt(3));
RD.setLead_price_rate(new Integer( (String) record.elementAt(4) ) );
RD.setLead_price_cat((String)record.elementAt(5));
}
How can I get these calls all to be in a single transaction so that if
an error in any set method, everything including create is rolled back?
--
tcp
Thomas Preston
Vacation.com, Inc.
Engineering Department
617.210.4855 x 124
==
=
To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
Re: JMS Question
Paul Jones wrote: Is there any possible way to set the message priority for a message when using a QueueRequestor ? This should be possible like this: Message msg = ... msg.setJMSPriority(prio); queueRequestor.request(msg); Best regards, Bjarne. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: Design question: entity beans, wrapping domain objects and su ch...
John Smith wrote: We want to take advantage of entity beans and CMP, but also want to preserve our Domain Object Model to the greatest degree possible. It is sometimes suggested that an entity bean simply wraps the java object. The entity bean would then have two attributes of interest to us, the id, and a reference to the java object it represents. Thus we never really act on the entity bean, instead we get the domain object from it, act upon it and give it back to the entity bean to persist. We may also do "large" queries using sql in session beans, construct our domain objects from the results, and when done, pass them back to an entity bean for transactional updates. I would like to expose only the domain objects to the clients (session beans) probably using a facade of some sort with which our "findBy" requests would be delegated to the actual entity bean and the facade would return back to the client, domain objects. Questions: First - I'd like to know if anyone is using domain objects wrapped by entity beans, and if so, can you provide some insight into how you actually use the domain object from a client. Thoughts? [Randy Stafford] Yes, we used domain objects wrapped by entity beans in the open-source FoodSmart example J2EE application on the "Developer's Guide" CD (freely available at http://www.gemstone.com). The entity bean encapsulation is controlled by a start-up property, so the app can run with either unencapsulated or encapsulated domain objects. We made design decisions similar to the ones you have in mind. Given domain objects, the only value entity beans provide is hooks for synchronization with persistent storage (and there are other ways of accomplishing that synchronization, that don't require the development and runtime overhead of entity beans). Therefore we just let our entity beans implement the same interface as the domain objects they wrap, and delegate basically all behavior (including relationship navigation) to the wrapped domain object. Our entity beans do implement a method called getDomainObject(), and that method is visible to clients of the entity beans (session beans and other entity beans). The existence of this method exposes a bunch of issues having to do with domain object distribution. If the domain object in question participates in a large transitive closure, such that it is not practically serializable, then you have to use other means of distributing that domain object's state to remote clients (e.g., remote clients of your session beans), and for performance and data integrity you probably also need to use container-provided mechanisms to ensure that all EJBs involved in a given system response run in the same VM and bypass the marshalling required by the EJB spec even when all EJBs are in the same VM. We do have one special-case usage of an entity bean for query search results, corresponding to your point above (see also http://www.c2.com/cgi/wiki?SearchResultAsEntityBean). Heres the first thing I come up with: Lets say we want to use a simple mutator on a domain object, for example, change a patients telephone number. 1 - the client makes a request for patient with last name of smith. 2 - If we were directly accessing entity beans from the client (session bean) we would have 3 remote references, update the one of interest and the container would insure it was persisted... In our case we get back three domain objects. We update the one of interest, and then what??? Sure, we submit it back for persistence. The facade will use the id to look up the entitybean, update it and persist it. But this seems like a lot of work! [Randy Stafford] Sure, because you have to find (create) the entity bean to update it (and you may have had to O/R map the three domain objects, too, which could be expensive). Any other ideas? [Randy Stafford] Yeah - don't use entity beans! I'm only being partly facetious here. If you've already implemented a domain model, the only thing entity beans are really buying you are the persistence hooks. Depending on what other persistence logic you've already implemented, this may or may not be valuable. The only other thing it buys you is some degree of dubious-value spec compliance (but probably not container-independence, due to the above-mentioned distribution issues). And as you're seeing, doing the wrapping comes at some cost. Entity beans don't handle significant domain complexity very well, due to issues around representing inheritence, relationships, etc. Entity beans are also all heavyweight remotable objects, and could saturate your server VMs and/or cause a lot of cycles to be spent on activation/passivation in a high-scale deployment. And this is to say nothing of the development effort required to get it all working and maintain it. biasFurthermore, you could save yourself the response time and
Re: Design question: entity beans, wrapping domain objects and su ch...
vendor We are working on that. We are going to put up a wiki with all the design patterns on-line. As far as NT vs. just putting the source out there for download, we wanted to automate an install procedure that would allow more novice folks to load it... But thanks for you suggestions, I'll take them to the folks that plan such things... /vendor Regards, -Chris. -Original Message- From: Guillaume Rousse [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, March 22, 2000 12:34 PM To: [EMAIL PROTECTED] Subject: Re: Design question: entity beans, wrapping domain objects and su ch... But only on CD and for Windows NT :-( Why not put them online, if they're really open source ? Le jeu, 16 mar 2000, vous avez écrit : John, The FoodSmart example application in our Developer's Guide wraps regular 'ol domain objects with Entity Beans. In fact we can use Entity Beans or not through some policy layers. This is all open source and available upon request from our WEB site. Regards, -Chris. -- Guillaume Rousse Iremia - Université de la Réunion 15 avenue René Cassin, BP 7151 97715 Saint Denis, messagerie cedex 9 Tel:0262938330 Fax:0262938260 ICQ:10756815 And now, some words for our sponsor : Explosives, guns, assassination, conspiracy, primers, detonators, Kakadan, initiators, main charge, nuclear charges, ambush, sniping, motorcade, IRS, ETA, FARC, Cuba, Castro, Che Guevara, revolution, ATTAC, BATF, jtf-6... == = To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: Design question: entity beans, wrapping domain objects and su ch...
But only on CD and for Windows NT :-( [Randy Stafford] Acknowledged. Why not put them online, if they're really open source ? [Randy Stafford] Stay tuned ;-) RPS Le jeu, 16 mar 2000, vous avez écrit : John, The FoodSmart example application in our Developer's Guide wraps regular 'ol domain objects with Entity Beans. In fact we can use Entity Beans or not through some policy layers. This is all open source and available upon request from our WEB site. Regards, -Chris. -- Guillaume Rousse Iremia - Université de la Réunion 15 avenue René Cassin, BP 7151 97715 Saint Denis, messagerie cedex 9 Tel:0262938330 Fax:0262938260 ICQ:10756815 And now, some words for our sponsor : Explosives, guns, assassination, conspiracy, primers, detonators, Kakadan, initiators, main charge, nuclear charges, ambush, sniping, motorcade, IRS, ETA, FARC, Cuba, Castro, Che Guevara, revolution, ATTAC, BATF, jtf-6... == = To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: Design question: entity beans, wrapping domain objects and su ch...
John, vendor The example application in GemStone/J's Developer's Guide does exactly this (i.e. wraps domain objects with Entity Beans). You can sign up for a copy at our WEB sute. /vendor -Chris. -Original Message- From: john smith [SMTP:[EMAIL PROTECTED]] Sent: Friday, March 10, 2000 11:17 AM To: [EMAIL PROTECTED] Subject: Design question: entity beans, wrapping domain objects and such... We want to take advantage of entity beans and CMP, but also want to preserve our Domain Object Model to the greatest degree possible. It is sometimes suggested that an entity bean simply wraps the java object. The entity bean would then have two attributes of interest to us, the id, and a reference to the java object it represents. Thus we never really act on the entity bean, instead we get the domain object from it, act upon it and give it back to the entity bean to persist. We may also do "large" queries using sql in session beans, construct our domain objects from the results, and when done, pass them back to an entity bean for transactional updates. I would like to expose only the domain objects to the clients (session beans) probably using a facade of some sort with which our "findBy" requests would be delegated to the actual entity bean and the facade would return back to the client, domain objects. Questions: First - I'd like to know if anyone is using domain objects wrapped by entity beans, and if so, can you provide some insight into how you actually use the domain object from a client. Thoughts? Heres the first thing I come up with: Lets say we want to use a simple mutator on a domain object, for example, change a patients telephone number. 1 - the client makes a request for patient with last name of smith. 2 - If we were directly accessing entity beans from the client (session bean) we would have 3 remote references, update the one of interest and the container would insure it was persisted... In our case we get back three domain objects. We update the one of interest, and then what??? Sure, we submit it back for persistence. The facade will use the id to look up the entitybean, update it and persist it. But this seems like a lot of work! Any other ideas? THANKS!!! __ Get Your Private, Free Email at http://www.hotmail.com == = To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: Design question: entity beans, wrapping domain objects and such...
they are lots of post here about domain objects. From what i've understood sofar, domain object was a synonym for business object, and were to be implemented using entity beans. Apparently, i'm a bit wrong on it. I found noting on this subject (domain object) on Cetus Link. Has anyone good pointers available ? Le ven, 10 mar 2000, vous avez écrit : We want to take advantage of entity beans and CMP, but also want to preserve our Domain Object Model to the greatest degree possible. It is sometimes suggested that an entity bean simply wraps the java object. The entity bean would then have two attributes of interest to us, the id, and a reference to the java object it represents. Thus we never really act on the entity bean, instead we get the domain object from it, act upon it and give it back to the entity bean to persist. Cheers -- Guillaume Rousse Iremia - Université de la Réunion 15 avenue René Cassin, BP 7151 97715 Saint Denis, messagerie cedex 9 Tel:0262938330 Fax:0262938260 ICQ:10756815 BRIDGEKEEPER: What... is the air-speed velocity of an unladen swallow? ARTHUR: What do you mean? An African or European swallow? === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: Design question: entity beans, wrapping domain objects and su ch...
John, The FoodSmart example application in our Developer's Guide wraps regular 'ol domain objects with Entity Beans. In fact we can use Entity Beans or not through some policy layers. This is all open source and available upon request from our WEB site. Regards, -Chris. -Original Message- From: john smith [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, March 14, 2000 10:51 AM To: [EMAIL PROTECTED] Subject: Re: Design question: entity beans, wrapping domain objects and su ch... Thanks for your response! I understand you want to wrap entity bean access in session beans, and I thought I stated we were doing that, I am interested in hearing from people who are going a step further and wrapping Domain Objects in entity beans. Here's what I am talking about: Client -- SessionBean -- EntityBean -- DomainObject The entity bean is a wrapper around the domain object, so my question was about accessing, using and updating the Domain Object from the session bean. How are people doing this? Thanks! From: [EMAIL PROTECTED] Reply-To: A mailing list for Enterprise JavaBeans development [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Design question: entity beans, wrapping domain objects and su ch... Date: Tue, 14 Mar 2000 10:12:44 +0100 We use entity beans to model our Domain Object Model. But the clients never use those entity beans. Instead the clients use Session beans, which internally use those entity beans. The session beans interfaces are modeled to provide some sort of low-level-use-cases to the client. All information the client needs is provided thru session beans. This information is either wrapped in serializeable objects or in XML, so the client can work locally on the data and send it back (thru a session bean) to the server Mit freundlichen Grüßen With kind regards Ulf Gohde System Architect CE Computer Equipment AG Fon: +49 (0)521 9318-167 Herforder Str. 155a Fax: +49 (0)521 9318-444 33609 Bielefeld mailto:[EMAIL PROTECTED] Germany http://www.ce-ag.com -Original Message- From: john smith [mailto:[EMAIL PROTECTED]] Sent: Friday, March 10, 2000 9:37 PM To: [EMAIL PROTECTED] Subject: Design question: entity beans, wrapping domain objects and such... We want to take advantage of entity beans and CMP, but also want to preserve our Domain Object Model to the greatest degree possible. It is sometimes suggested that an entity bean simply wraps the java object. The entity bean would then have two attributes of interest to us, the id, and a reference to the java object it represents. Thus we never really act on the entity bean, instead we get the domain object from it, act upon it and give it back to the entity bean to persist. We may also do "large" queries using sql in session beans, construct our domain objects from the results, and when done, pass them back to an entity bean for transactional updates. I would like to expose only the domain objects to the clients (session beans) probably using a facade of some sort with which our "findBy" requests would be delegated to the actual entity bean and the facade would return back to the client, domain objects. Questions: First - I'd like to know if anyone is using domain objects wrapped by entity beans, and if so, can you provide some insight into how you actually use the domain object from a client. Thoughts? Heres the first thing I come up with: Lets say we want to use a simple mutator on a domain object, for example, change a patients telephone number. 1 - the client makes a request for patient with last name of smith. 2 - If we were directly accessing entity beans from the client (session bean) we would have 3 remote references, update the one of interest and the container would insure it was persisted... In our case we get back three domain objects. We update the one of interest, and then what??? Sure, we submit it back for persistence. The facade will use the id to look up the entitybean, update it and persist it. But this seems like a lot of work! Any other ideas? THANKS!!! __ Get Your Private, Free Email at http://www.hotmail.com = == To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". = == To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTE
Re: Threads question (Concrete examples?)
Laird Nelson wrote: Assaf Arkin wrote: You need a more formal API to get into stage two. If you don't care about these features or portability, just pick any EJB server that allows you to start a thread (I believe most of them do), and use it. But if you care about the container features in your threads, about portability, about guaranteed behavior, try to stick to only well documented APIs. Like what? You mean container features, or well documented API? We all know the well documented API doesn't exist :-( arkin Cheers, Laird === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: Design question: entity beans, wrapping domain objects and su ch...
We use entity beans to model our Domain Object Model. But the clients never use those entity beans. Instead the clients use Session beans, which internally use those entity beans. The session beans interfaces are modeled to provide some sort of low-level-use-cases to the client. All information the client needs is provided thru session beans. This information is either wrapped in serializeable objects or in XML, so the client can work locally on the data and send it back (thru a session bean) to the server Mit freundlichen Grüßen With kind regards Ulf Gohde System Architect CE Computer Equipment AG Fon: +49 (0)521 9318-167 Herforder Str. 155a Fax: +49 (0)521 9318-444 33609 Bielefeld mailto:[EMAIL PROTECTED] Germany http://www.ce-ag.com -Original Message- From: john smith [mailto:[EMAIL PROTECTED]] Sent: Friday, March 10, 2000 9:37 PM To: [EMAIL PROTECTED] Subject: Design question: entity beans, wrapping domain objects and such... We want to take advantage of entity beans and CMP, but also want to preserve our Domain Object Model to the greatest degree possible. It is sometimes suggested that an entity bean simply wraps the java object. The entity bean would then have two attributes of interest to us, the id, and a reference to the java object it represents. Thus we never really act on the entity bean, instead we get the domain object from it, act upon it and give it back to the entity bean to persist. We may also do "large" queries using sql in session beans, construct our domain objects from the results, and when done, pass them back to an entity bean for transactional updates. I would like to expose only the domain objects to the clients (session beans) probably using a facade of some sort with which our "findBy" requests would be delegated to the actual entity bean and the facade would return back to the client, domain objects. Questions: First - I'd like to know if anyone is using domain objects wrapped by entity beans, and if so, can you provide some insight into how you actually use the domain object from a client. Thoughts? Heres the first thing I come up with: Lets say we want to use a simple mutator on a domain object, for example, change a patients telephone number. 1 - the client makes a request for patient with last name of smith. 2 - If we were directly accessing entity beans from the client (session bean) we would have 3 remote references, update the one of interest and the container would insure it was persisted... In our case we get back three domain objects. We update the one of interest, and then what??? Sure, we submit it back for persistence. The facade will use the id to look up the entitybean, update it and persist it. But this seems like a lot of work! Any other ideas? THANKS!!! __ Get Your Private, Free Email at http://www.hotmail.com === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: Threads question (Concrete examples?)
dan benanav wrote: Does this mean, for example, that I cannot use Hashtable or Vector in my bean classes? Yes you can, as long as they are not shared between two threads. This answer doesn't make sense to me. Either you can use a hashtable in an entity bean or you cannot. It's not that simple. You can use a hashtable (or whatever), as long as the way you use it doesn't interfere with the App-server's operation. Specifically, you can use a hashtable as long as two beans, executing in two different threads, don't simultaneously try to call methods on the same hashtable instance, because then the calls would get synchronized, and that's prohibited by the EJB spec: 18.1.2 ... An enterprise Bean must not use thread synchronization primitives to synchronize execution of multiple instances. Later, Rujith. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: Threads question (Concrete examples?)
Assaf Arkin wrote: You need a more formal API to get into stage two. If you don't care about these features or portability, just pick any EJB server that allows you to start a thread (I believe most of them do), and use it. But if you care about the container features in your threads, about portability, about guaranteed behavior, try to stick to only well documented APIs. Like what? Cheers, Laird === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: Threads question (Concrete examples?)
This answer doesn't make sense to me. Either you can use a hashtable in an entity bean or you cannot. Why should I worry about threads now? Don't worry, just use it and be happy, but if you want to be on the safe side, you should consider the 1.2 collections. arkin If you use a Vector or Hashtable from one thread and something happens to your thread inside the synchronized stuff, your Hashtable/Vector might be corrupted. But you shouldn't care. IF something happens to your thread, the EJB server will discard that bean (always). If you are using two threads and something happens to thread A that leaves the Vector in an indeterminate state, then thread B might break and you have no control over that. I've just implemented some piece of the CMP engine that manages locks using synchronized. I expect that something might happen to the thread since the EJB server controls it, and have extra (even redundant) code just to make sure that never happens. In the Java 1.2 collections Sun addressed that by writing the collectors so they do not rely on synchronized. arkin Cheers, Laird === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". -- -- Assaf Arkin www.exoffice.com CTO, Exoffice Technologies, Inc.www.exolab.org === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". -- -- Assaf Arkin www.exoffice.com CTO, Exoffice Technologies, Inc.www.exolab.org === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: Threads question (Concrete examples?)
Assaf Arkin wrote: Mark, So far the discussion has been about the useability of thread support, and no one contradicted their usability. I'm not sure JMS is sufficient for what developers have in mind, and connectors would be an overkill for many applications. It's clear that EJB 1.1 should not support threads, nor the applications should attempt to use them. But what about adding that support to a future version of EJB? If enough people request it, you will see it being supported by the major vendors, which unless properly specified, will break the WORA promise of EJB. I would have to support this. We have already added our own proprietary thread management API for use by EJBs, since our customers cannot wait any longer for this. We would love to see this area standardized. Evan Ireland Sybase EAServer Engineering[EMAIL PROTECTED] Wellington, New Zealand +64 4 934-5856 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: Threads question (Concrete examples?)
Rickard Öberg wrote:
I don't see any compelling reason to make another type of bean that
duplicates the functionality already available in JMX. JMX beans are
portable between different servers supporting JMX, they are manageable,
they can interact in whatever fashion you like with EJB's, etc etc.
Really? Don't they open sockets and listen for incoming management
requests on them? Isn't this in violation of the EJB 1.1 specification?
{rummage rummage rummage}
Cheers,
Laird
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
Re: Threads question
Laird Nelson wrote: By this logic any time I use java.util.Vector in my bean code I am violating the EJB 1.1 specification (beans can't use threads or synchronization primitives; third-party classes used by beans can't use them either; java.util.Vector uses synchronized all over the place; therefore java.util.Vector is in violation of the specification; therefore my bean is in violation of the specification). The spec says: An enterprise Bean must not use thread synchronization primitives to synchronize execution of multiple instances. So you can use Vector (and its ilk), as long as only one enterprise Bean at a time uses each instance of a Vector, because then you're not synchronizing execution of multiple enterprise Beans. - Rujith. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: Threads question (Concrete examples?)
I find compelling Assaf Arkin's formulation of the problem: EJB allows for synchronous processing; JMS allows for asynchronous processing; neither allow for continous processing. I wonder if parallel workflow requires continuous processing, as you suggest. Consider a workflow with three parallel tasks implemented on an EJB 2.0 server. A session bean implementing this workflow would send a message to three "helper" session beans and return. Each session bean would implement one task (in parallel with the other two.) As each finished, they would send a message to a "task completed" session bean, which would wait until all three tasks had finished. In fact, in my experience those workflows would frequently require user interaction. A session bean implementing a task would insert a record into a database, and/or notify a user via e-mail, and disappear until the user responded. You certainly don't want a thread hanging around until the user gets around to checking his/her "to-do list." You might want a "semi-continuous" process to check for those instances where the user goes on vacation. But this can be a database-scanning session bean triggered by JMS at a certain interval. Again, you don't need to roll your own threading logic. The lack of continuous processing may be a hole in the specification if a complete enterprise platform is desired. But I would need to see a more specific example to believe that EJB 2.0 (i.e. EJB + JMS) cannot handle the common business problem of parallel workflow. -Dan On 28 Feb 00, at 15:00, Laird Nelson wrote: - Original Message - From: Mark Hapner [EMAIL PROTECTED] A major objective of EJB is to achieve the creation of a multi-user service by implementing single threaded components. So EJB was never intended to handle parallel workflow, as occurs commonly in large business systems? Then what good is a session bean? EJB 2.0 will significantly expand the EJB app domain by adding support for asynchronous invocation (JMS integration). Which is only half of the problem. EJB will not be complete until it also specifies how to "create" threads within user beans in such a way that the container still has a handle on them. This is a very simple problem. So, the question is not what you can do within your container it is what your container can do for you :). Why should you be worrying about creating threads if you can get the container to handle all of that complexity? Because no container on the market will currently let me do parallel asynchronous workflow while still being strictly EJB 1.1 compliant. That says more about the specification than the container to me. Cheers, Laird === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: Threads question (Concrete examples?)
Assaf Arkin wrote: People on this list have come up with usage scenarios where, you have to agree, neither EJB 1.1 nor EJB 2.0 + JMS are sufficiently addressing their needs. The issue here is not about redoing thread pooling and thread management instead of the container, but being able to get a continueous background process to run inside the EJB container. And if enough people do need it in their production environment, then it should be addressed as a WORA issue and become part of the specs. I second that opinion. We shouldn't have to expose proprietary features to do service (startup-time) components and thread management. However in the absense of adequate standards, we are forced to expose proprietary features to allow customers to do what they need to. Evan Ireland Sybase EA Server Engineering [EMAIL PROTECTED] Wellington - New Zealand +64 4 934-5856 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: Threads question (Concrete examples?)
dan benanav wrote: All I was asking about is what would happen if I create a new thread from within a bean method and then get an InitialContext in the same way that I would from a client thread. I was wondering why that wouldn't work. As an example, the lookup method on the InitialContext (in the server case) might attempt to make an inter-component call to the naming service. If the server requires all inter-component calls within the server to be done from container-managed threads, the lookup call will fail. Anyway this is just an example, since the way the spec is written actually permits the use of JVMs that don't permit explicit thread creation at all. Evan Ireland Sybase EA Server Engineering [EMAIL PROTECTED] Wellington - New Zealand +64 4 934-5856 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
Re: Threads question (Concrete examples?)
Sorry, I don't see how instrumentation and SNMP agents are useful for building an enterprise solutions where your operations are transactional, involve complex objects, and require TP monitoring. I was not referring to the ability to control services, but rather the ability to control disributed transactional processes that are part of your application logic. arkin "Rickard Öberg" wrote: But JMS deals with asynchronous invocation, whereas threads deals with asynchronous processing without the overhead of sending messages all day long (= more code to write, more code to debug, more CPU time to waste), and with the ability to interact with a process in progress. If you send a JMS message you might be able to start a process and get a response when it's done in an asynchronous manner, but you cannot interfere with a running process, since you have no mechanism for a running process (i.e. threads). This seems like a perfect fit for making this kind of functionality a JMX MBean. (see http://www.javasoft.com/products/JavaManagement/index.html). I don't see any compelling reason to make another type of bean that duplicates the functionality already available in JMX. JMX beans are portable between different servers supporting JMX, they are manageable, they can interact in whatever fashion you like with EJB's, etc etc. /Rickard -- Rickard Öberg @home: +46 13 177937 Email: [EMAIL PROTECTED] http://www.dreambean.com Question reality === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". -- -- Assaf Arkin www.exoffice.com CTO, Exoffice Technologies, Inc.www.exolab.org === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
