Nitzan Levi

Greenhorn
+ Follow
since Feb 19, 2003
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
In last 30 days
0
Forums and Threads

Recent posts by Nitzan Levi

hi,
i'm not sure i understand your question but if you mean where is the information about the durable subscriber it self then the MQ has an admin queue(i think it's SYSTEM.JMS.ADMIN.QUEUE) and also he has queue for the broker that also saves details about the subscribers(i think it's something like SYSTEM.BROKER.IO....).
hi,
the get parameter is used when you want to get the http parameter's value that came from the user(via html)for example <input type='text' name='myParam'></input>
so when you do getParameter("myParam") you will get the value of that input field.
the get attribute is used when you want to get an attribute value that came from other servlet or JSP. that will happen only if the first servlet or JSP that got the request from the user activated the request.setAttribute("myAttribute","some value") and then activated the requestDispatcher("other servlet or jsp uri").forword(request,response)
hope that helps!
21 years ago
hi,
yes there is a class(or classes) that implements those interfaces, but you'r not suppose to see them. this classes are implemented by the web container provider and you'r using those classes by activating the interfaces.
hope it helps !
21 years ago
are you using the wsad or the eclips ?
when using wsad all you need to do is double click on the line and run the server in debug mode. i think this option is the same in the eclipse ?
21 years ago
hi,
you have to seperate the bean as a java class from the bean as a data entity. when you activate the find method you are using the bean class(witch can be one of the 10 or 15 generated classes that the dev tool is creating) to check if the data exists in the DB according to the PK.
the PK returnd from the find method is not for the user it's for the container that then creates an entity bean(EjbObject) that contains the data represented by the PK and thats what the user gets. now the user can work with the entity beans data .
hope it answers you'r question!
hi,
there's two ways that standarts can be made
1. using framworks
2. by contacts
in java pure java the way is with framworks using interfaces ,abstarcts classes and other utilities.
in j2ee it's with contacts(the specifications).
because j2ee is a java oriented parts of the standarts are using java style(interfaces) and parts are with contacts.
the ejbCreate methods are stadarts that uses contracts , you won't find this method in any interface , but the development tool(on asembly time) in validation time will check if you defined the ejbCreate methods(and the postCreate also). if you'll think about it there's no way you can define ejbCreate with interface because it's the bean provider decision witch "constractors" he want's to write !!
hope it helps you
hi,
basicly as a developer it's not you concern how the server dose this kind of work , but what you do need to understand is that when you work with cashing it's importent that you don't access the DB directly it can cause inconsistency between the DB and the container.
when you choose to work with server cash then the container decides when to go to the DB and when to go to the cash in order to provide both data consistency and best perfomence. the server decides to save a bean in cash according to the emount of memory and the frequency of the bean use. i dont think that the server is making cashing for the finder methods but i think he dose it for the beans(the real instance of the bean).
if you want more vendore specific information you need to go the the vendors web site(for example ibm for websphere)
hi,
it's very importent to know what's the future use of the application. if it's a small application that will always run on a single server then you can use the static approach that will be the simplest and with less cost.
if your application needs to run in a clusterd environment than you need a more copmlex solution and the entity bean will be a good one. the cost of an entity bean (if you dont use persistence) is minimal for that complex environment !!
like every solution there's a pro's end con's the best solution depends on the requierments
hi,
let me understand currectly , the subscribing part is successfull and the publication also , and the clients don't get the messages ??
hi,
you can use a statefull session bean that will do the orders , the OrederCrosserBean will get the handle to this statefull from the jndi(only when it realy needs it) , and if another OrederCrosserBean instance is currently working with this statefull then the container will throw you an exception. then you can deside if you want to try untill the statefull will be free or not !
hi,
you need to supply more information about the failure, and what was the changes in the server/client configuration that you'v made !
hi,
1. MQ is implementing the JMS standart so when you say that MDB can work with JMS it means that it can get meassages from MQ (if u uses it for you JMS implementation).the all idea of JMS that it hides the MQ or other MOM provider's API .
2. there is no problem for a standalone java(and other) application to send messages to the MDB. you can do it in two ways :
1. the java application will take the JMS administered objects(connection factory , queue,topics) from the jndi and work exactly the same as it would inside the container !!
2.the java application can create those objects with the standart JMS api with no JNDI use!
the best way is the first way because that way you can change the administered objects parameters in one place !
hi,
what do you mean by one entity for "a lots of tables" ?
hi,
i dont think that the DAO goal is to reduce the number of entity beans. it's goal is to decouple the entity bean with the specific data storage implementaion(relation DB , or other DB).
the way you need to reduce your entity beans is by designing the entity as a component that contains a joined data from number of tables. you can create a number of DAO's for each table and in the entity bean store and load methods work with the DAO's according to the changes made by the entity bean. that way it would make it more easier to write and maintain the persistence specific code (JDBC in your case).
hi,
i would check the database driver , or check if the data base is active the all time .
if you can ,install another database db2 for example ,and test if the problem accur , then it would help you to decide if the problem is within the WAS implementation .