Win a copy of Mastering Corda: Blockchain for Java Developers this week in the Cloud/Virtualization forum!

John Pradeep.v

Ranch Hand
+ Follow
since Jul 21, 2008
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
1
Received in last 30 days
0
Total given
1
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by John Pradeep.v

david arnold wrote:Hi,

I am maintaining a web application which use struts 1 and web service(WS). I found that there are some WS calls which are very common that every user will repeatly need it (resulted object is same for everyone). Since WS call take times and some function need to do a few WS call in a row, the performance is not good.

1. First solution in my mind is to save the WS call result (object) in the session when the user got it from the WS call for the first time, then try to retrieve it from session whenever the user want to use it again.
2. Second solution: when deploy the application, call those WS functions and save the resulted object somewhere (in session?), then each user can get it when it is needed. I don't know how to do it if this method is applicable.

Not know which solution is better or there is other better solution? Any advices?

Thanks.



Looking at your explanation, the data returned by the web service is independent of the user in context. i would suggest you to cache the response using a good lightweight caching framework.

For example, if you have a service "ServiceA" which has operation "getData" which internally makes WS call and returns objects as return value. then it would be a nice idea to intercept the call to getData (using AOP may be) and get the data from internal cache... if you dont find the data in cache then delegate the intercepted call to the actual service and on return place the value in the cache for further use.

This way you wont have stale data in your cache if the web service response changes time to time...

Hope this helps.


John
10 years ago

Alex Hurtt wrote:I would try and take a multi threaded approach to this problem if possible. Maybe you could make a thread pool of size 10 or so and hand off 100 element chunks of the list to worker threads to process. I just pick 10 as some arbitrary number...I have no idea what this list actually contains or what you are trying to do with the data. You would have to find the right balance of chunk size and number of threads to yield you the best performance.



Just to add to what Alex said, if you have any IO operation to read the huge data to memory then the IO operation should be done in a single thread, having multiple threads doing IO operation will be slow.
however, you can use few threads to process those data read into the memory..

10 years ago

rahulj rjagtap wrote:hi,
all
I want to maintain the state of checkboxes across pages.
What happens is when i check one checkbox and then go to say 2nd page then check one checkbox there and when i return to previous page the checked box is again unchecked.
Means the status of the checkbox is not maintained.If it is maintained then it should show checked.

I am using jsps and display tag in jsp for pagination.
Any kind of help would be greatly appreciated.



i think you should be capturing the values entered by the users somewhere in the session? your checkbox code should contain a conditional way of making it checked or unchecked like below.

<input type="checkbox" checked="<<read the previous value form session>>" />
10 years ago
JSP

ujjwal soni wrote:Hi,

I am creating a cookie with Struts action called using Ajax function, after cookie gets created, i am reading it on the same page but i am not able to get new cookie name/values, if i refresh this page, i am able to see new cookie value. So, is it necessary to refresh to get new cookie values ?



Can you please post the piece of code where you read the cookie?
10 years ago
JSP
are you trying it jus to experiment with threads? if not then using so many threads to find the nth fibonacci number is a no no.

The number of threads you use in any program and the synchronization between them should be choosen carefuly otherwise it will eat up memory and processing speed of your computer.... using so many threads along with recursive is again a wrong approach.

Binet's Formula finds out the nth fibonacci number with few multiplications and divisions.

Mobio Dev wrote:
this is my bean
--------------------
private byte[] templateContent = null;
public String getHtmlTemplateContent() {
return templateContent.toString();
}
public byte[] getTemplateContent() {
return templateContent;
}
public void setTemplateContent(byte[] templateContent) {
this.templateContent = templateContent;
}
public void setTemplateContent(Object templateContent) {
this.templateContent = (byte[])templateContent;
}

this is my action
-------------------
templatesDataBean = (TemplatesDataBean)SendEmailManager.getTemplate(action, actor, sendEmailBean);
sendEmailForm.setTemplate(new String(templatesDataBean.getHtmlTemplateContent()));

how this can be solve, thanks in advance



When you say toString() on the byte array it doesnt give you the actual string pushed into the array, you should ideally pass the byte[] to the String constructor... i think if you avoid calling toString in the getHtmlTemplateContent() and just create a new string by passing the byte array as parameter would solve the problem
10 years ago
i think it will definetly improve the performance as most of the UI processisng/building logic is moved to the UI layer (client machine), its as if you are moving towards the thick client approach

in your case of providing JSON response, i would suggest you to expose services (RESTful) which accepts request and provides response rather than a MVC frameworks... have a look at apache tuscany, which would make things easy for you.


10 years ago
you can remember the logic behind this behvior by understanding the bytecode generated.
for normal method call, the compiler generates an "invoke" instruction which resolves the target class type at runtime... however, when a private method is called the compiler generates an "invokespecial" instruction which doesnt try to resolve the target method based on the instance type.


Adding to what Nathan said, leaving the object creation strategy to a Dependency injection container makes it easy to inject mock version of the dependencies and test the class under isolation.
Nevertheless, the DI framework can be instructed to maintain a single instance of the class...
10 years ago
Hi Venu,
Instead of finding the special character (black listing) just extract those characters you are interested in... (white listing) this way you dont have to maintain a huge list of special characters.


10 years ago

Kumara Sharma wrote:Good Morning,

I had seen quite a lot of Java code & written some.
Most of the code I saw/see & I write, it is the Procedural way.
There will be a method of 400 loc, with if-elses, whiles etc and all..implementing some business logic..
How can I learn to program Java in Object-oriented way.

Any resources on-line/book names would be greatly helpful.

Thanks.



There are lots of books on OOAD, the best i have read is "Applying UML and patterns" by Craig Larman, but before reading this book you read head first OOAD.
After you read both the books, then you can consider reading Domain Driven Design by Eric Evans & Patterns of Enterprise architecture by martin fowler to get a bigger picture of good design principles.


Regards,
John
10 years ago
Hello All,
I am new to Jboss... i am trying to understand the high level architecture of Jboss to start with, what i understood is that Jboss integrates tomcat into Jboss as a service to support web applications. But i do want to understand how does a web application deployed in tomcat (jboss service) can identify and interact with the EJBs deployed separately on the same Jboss server.
What would happen if i use EJB annotations like "@Resource" in classes present in the web application? since the tomcat will have its own class loader structure, how does the dependency injection will work for the classes present in the web application (loaded by tomcat) when we try to inject EJBs?

Another question - how does the web server generally interact with the application sever? is it always through sockets? or is it different for different types of EJBs (local & remote)?


Thanks
John
10 years ago

David Newton wrote:Not really, but that's okay.

I always go through a service, even if it's just a delegation to a DAO. This allows me to put aspects around all my service methods and leave my DAOs alone, which in turn means that I don't need to do anything in particular for services that use multiple DAOs, and the service methods that wrap DAO calls can be generated automatically. There's an interface that defines DAO operations, each related service implements the same interface. Services also implement their *own* interface that defines functionality beyond that provided by its underlying DAO. Some services, of course, aren't tied to a single DAO.



This was exactly the same approach i followed, but somehow i felt the services to be more process oriented rather than single operation oriented for example i can have a BookingService which can do a booking for an inventory (make payment, update inventory etc etc) but adding a new inventory to the database need not be in the "BookingService" interface right?
even if the service encloses the operation like "addInventory(Inventory inv)" the name of the service cannot be meaningful, but in fact did have such services and named them like "InventoryService", "EmployeeService" which are not business process services but EntityServices.

Having such EntityServices is not harmful, but then i thought having too many delegators (Entity Services) would be lot of noise and then thought of using the Repositories directly in the facade which is when i thought i will find out others opinion and created this entry in javarach :)


I have yet to see a great reason for a facade between controllers and services;



The reason for such a design is that is that it not only seperates the controllers from the business layer but makes the controller look a bit neat and clean by providing a proxy like interface which does various operations like
1. Identifying the service using business layer factory
2. Prepare Input to call the actuall business service (if required)
3. Call the service
4. convert the business layer objects returned by the service into UI layer objects

The controller will just have to call the operation of a facade by passing a view layer input object and obtain back the view layer specific object, but behind the screen the facade does all the above mentioned operations.

I do agree strongly that there is no great benefit i gain out of such an indirection, but its just i dont want the controller to get bloated in the future due to the absence of a facade layer!
However, if the amount of code required to co-ordinate with the business layer is simple, then i dont mind doing it directly in the controllers though.



David Newton wrote:
Honestly, I have no idea what your class diagram looks like, and it sounds over-architected to me, so I doubt I'll be able to provide much more useful input. I don't understand how many layers you have, how they interact, how they're used, why the exist, and so on.



I understand David, I will try to give a glimpse of the layers i have used.

The layers are as shown below

1. Persistence
2. Domain
3. Service


4. Facade
5. Controller
6. JSPs



1,2,3 layers together is one single layer so is 4,5,6 together

the first set is the domain layer which is designed based on the domain driven approach and the second set is the view layer.

The Service layer is the business layer which provides business services

The facade layer is like an adapter to decouple the view layer (controllers) from the Service layer, when i say it decouples it actually transforms the classes present int he domain layer into a form used by the JSPs so that JSPs are not coupled with the model classes present in the domain layer
Also the facade layer co-ordinates between multiple services if required after all it is named a facade.

Hope you got the idea now, the facade layer need not always talk to the service layer because there could be a simple CRUD operation on an entity required so the facade layer can directly invoke a Repository (present in the persistent layer) to do the CRUD operation on the entity.
Example: EmployeeRepository.add(Emplyee emp);

Did i make things clear now? :)

David Newton wrote:Having the DAOs handle transactions is *not* a clean choice, because the DAOs then have to understand the context in which they're being used. If you're working in an environment that allows nested transactions they don't have to worry about it. If you're not, you're either going to have to add a flag, or have the DAOs understand more than (I believe) is reasonable about the world in which they live.

YMMV.



But in the example i mentioned, the client for the Repository/DAO could be even a facade class present in the "View Layer", handling transaction in this layer makes me a bit uncomfortable :(
but i could avoid it by having the facade layer talk to a specific service class within the business layer which will just delegate the call to the actual DAO/Repository and in this case i can handle all transaction at the service layer "alone"!! which is really convincing to me but as a worst case there might end up quite a lot of delegators bloating the code base! what's your take on it?
I feel, as you said having a flag would solve the problem but i should ensure that these conditional code of handling transaction is seperated out using AOP