Win a copy of Beginning Java 17 Fundamentals: Object-Oriented Programming in Java 17 this week in the Java in General forum!

krithika desai

Ranch Hand
+ Follow
since Apr 02, 2003
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by krithika desai

Originally posted by Pradeep Bhat:
You can use Views for this purpose. Some app servers like weblogic have explicit support for this.


I have used database views only to select. Never used it for insert and update :roll:
Now that weblogic allows me to map entity beans to views, it knows to insert into tables that make up the view ?
Have to brush up my database skills

Originally posted by Sivasundaram Umapathy:
Portability is indeed a vague term.In a real scenario,how many time,we change the application servers and databases?So why should one consider the portability aspect,if they had really made their mind on the infrastructure(h/w and s/w)?
Just a thought


But if you are selling a product then you might have to deploy it on a server that your client has already invested in.
If i understand rishi's query properly, Is'nt he questioning this? -->

Originally posted by Prashant Satarkar:

In other words: The identifier OBJECT in the SELECT clause is required, because the OBJECT operator must qualify all stand-alone identification variables in the SELECT clause.



Either way guess OBJECT is not required for
SELECT p.company FROM Person AS p
where company is a CMR with Company entity bean.
So Rishi if I understand your question correctly, are you saying that when OBJECT is not used here to identify the Company bean why is it needed to indentify the Person bean in the query you posted?

Originally posted by Sainudheen Mydeen:

When working with large volume of data, which one is easy to implement and provides better performancea? EntityBean OR JDBC?
-Sainudheen


From the discussions in the EJB forum , looks like finders and ejbSelects and bean traversal through CMRs results in lots of performace issues when dealing with huge volumes of data. So JDBC is the recommended way atleast when processing existing data ( ie read only ).
As Ko Ko has already pointed out, Weblogic is probably the most well documented and easy to use app server and it has a 1 year developer license too. If I were you, I w'd go with weblogic.

Originally posted by Pradeep Bhat:
I guess it means - Not to define a class using the ClassLoader.defineClass() method.


pradeep,
W'd it be correct to interpret this as " do not use your own custom class loaders within the EJB container " ?

Originally posted by Ko Ko Naing:
I think you have missed the following thread, in which it said that JDO and EJB are not comparable... It's interesting too...
https://coderanch.com/t/158140/java-EJB-SCBCD/certification/JDO-EJB-Future


Well, i mentioned "Entity" beans specfically and not EJB. Are'nt Entity beans and JDO primarily designed for persistance?. Yeah the post is informative but does'nt address my question though :roll:
looks like India bashing is a favourite thing these days! :-)
18 years ago
I just want to get my basics right! this statement is something that i see everywhere.
1. Both of them provide a Object view of the persistant store.
2. JDO is lightweight because it does not involve 3 interfaces ? :-) to represent.
3. Entity bean model essentially loses out on performance because of the life cycle methods that a container needs to invoke?
Can somebody confirm if 3) is one of the reasons an entity bean is slower than other mechanisms? If that is the case, can this call back specifications be refined to make it work faster?

Originally posted by viswanadh kasinadhuni:
hi prashant,
First of all everything is reinvented by sun..like entity beans...its concept is nothing but like views of a rdbms..right. ofcourse they have a lot more advantages than views..but still the basic is duplication of data and now EJB-QL for querying the objects..another duplicate work. why not just use session beans and use sql and rdbms avoid entity beans completely. Lets wait and see what SUN says about this.


So you are basically questioning the Object-Relational mapping then which is what entity beans ultimately do?

Originally posted by Sivasundaram Umapathy:
Ko Ko Naing is here,only to help us.


thanks ashish, pradeep,
that helps. I guess the app servers do allow us to configure the number of retries then?.
Pretty basic. If i send a message to a MDB and an exception gets thrown while performing an operation, depending upon my trans-attribute setting, things will be rolled back or otherwise?.Now does the message that I sent get back to the message queue? and will it retry the whole thing again later @ some other point of time?
If it does is there any timeout and max tries setting?

Originally posted by Pradeep Bhat:
EJB has a good future. Entity beans overhead and persitent frame work are little lacking. JDO can be used with entity beans.


ok I fail to understand this. It might be very basic. Will using JDO to provide CMP implementation improve performance drastically? What is it that brings down Entity bean performance?. The life cycle? , the way callback methods work? Guess it has to be. Ultimately SQLs have to run in the background. I have a feeling that what needs to happen in the ejbLoad and ejbStore , callback method calls brings down the performance?
If that is he case, how w'd using JDO improve performance.
If this is complicated, this is my actual question:
What is it that is there in the spec that brings down the entity bean performance?

Originally posted by Pardha Akalamkam:
Hi Kathy/Bert
With a lot of hype and enthu over JDO do you think EJB technology would sustain for a long time.Is it advisable to buy the book "head First EJB" and study for SCBCD. What is your opinion about EJB's future against JDO.
Pardha
SCJP
SCWCD


from what I infer from the posts in the forums,
EJB = entity + stateful session + stateless session + message driven bean.
winners --> stateless session beans & message driven beans
losers --> entity beans + stateful session beans.