Roger Thornhill

Hi George and Danilo,

I was wondering if you had any thoughts on which Struts "patterns" have proven to be the most popular or important.

You may cover this already in your book (which I intend to read), but I was wondering if you can give us a quick summary of which patterns seem to most important.

Of course, Struts itself is MVC and the View Helper pattern is one I know that is popular, but what other controller or view patterns come to mind?

Thanks.

Hi Jason,

Thanks, I will move the thread.

BTW, you guys might consider noting this information when you send out the periodic e-mail about new book promotions. The only information I get in those e-mails is that a new promotion exists and a link to the BB url for it (which is this thread). Maybe this is made clear somewhere else?

In any case, thanks for the advice. I will move the question to its own thread.

Hi George and Danilo,

I was wondering if you had any thoughts on which Struts "patterns" have proven to be the most popular or important. I have not yet read your book, but I assume that the the notion of "recipies" relates in some sense to common solutions to common problems.

Thanks.

Hi -

I was wondering if the authors had any information on the extent to which Lucene has been successfully deployed in large non-commerical or commerical applications. Pointers to specific sites would be very much appreciated, but even anecdotal references / testimonials would be helpful.

Thanks very much!
[ January 05, 2005: Message edited by: Greg Barish ]

Purify is VERY useful for spotting memory leaks in C and C++. For Java, I would imagine it is telling you things like: (a) how many instances of various objects are active during execution, (b) where those instances were allocated, (c) call graph information related to why the function that allocated them was called, etc.
In general, memory profiling tools like Purify help you identify the source of memory consumption inside your Java application. Leaks are less common in Java due to the GC, but they still happen, depending on the details of your application. Also, folks tend to use tools like Purify to optimize their memory usage (i.e., minimize it).

Originally posted by Raj Bhalla:
1)Session beans limit the number of stubs used on the client memory and processing cycles.??

It may or may not, depending on the application. It's really hard to say, given that we don't know anything about your application.
But I will say this: what you're worrying about here is a minor implementation detail. It is far less important than getting the design right.
Use session beans if they make sense in the design of your app. You could design session bean interfaces with methods that are more or less coarse in their behavior - and this might affect performance - but even this is a detail, when compared to the overall design.

Originally posted by Raj Bhalla:
2)Session beans reduce network traffic and thin down clients.?

Without knowing any more details about your app than what you provided, one cannot know about the network traffic issue. If part of your business logic involves validating user input - and you could have done that in Javascript on the client side - then no, you probably will not reduce network traffic. But in other cases, the answer might be yes. We really need to know more about your application.
WRT thinning out clients: yes, obviously session beans would do that because they encapsulate your business logic on the server side, not on the client side. Thus, it follows that client side logic will tend to be smaller.
I will also add this: one of the benefits of using session beans is that you can centralize your logic and appeal to many types of clients. Suppose you had a voice interface and a web interface to your application. If you put the business logic in the clients, you will have to replicate logic - always a dangerous game because of the error and inconsistency you invite. Also, it may not be possible to code the business logic in some of your clients, forcing you to use a session bean anyway.
Anwyay, if you provide more detail about your application, we might be able to help you better.

Does
Connection conn = DriverManager.getConnection ("jdbc: oracle:thin:@wendb","wen","wen");
work?
[ May 26, 2002: Message edited by: Greg Barish ]

Hi Cristan,
Just a quick followup. I didn't want to come across as if there was never a case for application-level record locking. There is. You see it a lot in places where many people have administrative access to a common piece of data (ie, your registration information at school, your patient record at a hospital, etc). At such places, it is sometimes the case that an administrator wants to edit that record, but cannot because another admin is editing it.
But, even in these types of scenarios, there is still no expectation -- for those just viewing data -- that the current data on their screen is still valid. The only time that is the case is when the very operation they are doing (e.g., edit) guarantees that. Now, it might be possible for someone to demand that "viewing" requested data also locks that data, but it is not a common requirement and it would seem (at least to me) that the application would be frustrating to use, especially in places like a hospital or school etc.
Anyway, I just wanted to clarify that point. Also, if you do want to implement application-level record locking, you don't necessarily need to have a "Lock" button. The very nature of the operation (e.g., edit) might necessitate locking, so the "edit" button would actually correspond to "lock this record and go into edit mode".
Anyway, hopefully this clarification has helped more than it hurt.

Typically, this is not something you should worry about. It is commonly understood that data on a screen is stale the moment after it is queried. The user normally has no expectations that the data will remain the same (i.e., that some other user isn't modifying the data).
The solution for cases where you need logical record locking are to implement features that permit just that. For example, if your application was a database full of memberships, you would have a button that said "Lock this membership" so that you can edit it. Then, you would implement application-level entity locking.
But again, if you design your roles and responsibilities correctly, this is often not a problem. For example, on JavaRanch, I know that only I and an administrator can edit my profile (at least I hope so!). I have no expectation that while I am viewing my profile data that noone is behind the scenes editing it. Administrators, generally, know what each other is doing (there should not be too many administrators) and/or have domains of administration.
It's only in cases where you have many administrators without well-defined boundaries that you need application-level record locking support.

I'm glad you elaborated a bit more about the scenario -- it helps with diagnosis. What about using Java to prepare SQL*Loader input files, which you can then use with the sqlldr executable? I think you could probably still capture the conditional inserts you need. (Alternatively, I think SQL*Loader supports conditional inserts, however the expressivity it provides may not be enough)
To capture the need for specifying table constraints, you could generate a SQL schema file (either manually or with Java). Then you could use SQL*Loader to populate the tables you create.
However, if performance of bulk insert is your goal, and you know that your data already obeys the constraints you need, it will likely be more efficient to first bulk load the data (with no constraints) and then modify the tables with constraints later. Generally, things like constraints and indexes will slow down the shoveling process.
[ May 22, 2002: Message edited by: Greg Barish ]

I second Mark's hint. For a one time batch transfer of data to Oracle, SQL*Loader will almost certainly be your most efficient option.

BTW, Strings already implement Comparable, so you really don't need to do anything. Just stick the String objects in your ArrayList and call Collections.sort().

Collections.sort() is a simple and easy way to do that. But remember that the object being sorted must implement Comparable.

Brian, also just as a followup, here are the rules on how various combinations of datatypes in arithmetic expressions impacts the type of the result:
http://java.sun.com/docs/books/tutorial/java/nutsandbolts/arithmetic.html

You might want to post the version of Java you're running and your CLASSPATH. Five minutes to compile a file is a bit long!