Daniel Hedrick

Uh, you might want to check the API for Hashtable. AFAIK, it does not promise any type of ordering. If you want your elements in a particular order, use a Collection class that supports it.

Good luck!

-daniel

Not to send anyone away from Javaranch, but I recently came across this very useful tidbit that I think might be useful if you have a considerable amount of data to shuffle about:

http://developer.apple.com/internet/webcontent/iframe.html

Good luck!

-daniel

Not to send anyone away from Javaranch, but I recently came across this very useful tidbit that I think might be useful if you have a considerable amount of data to shuffle about:

http://developer.apple.com/internet/webcontent/iframe.html

Good luck!

-daniel

Adeel:

isn't it better to check at the time of update. just match the previous values from the DB values.

Yes. I think we're saying the same thing. But instead of doing something like:

UPDATE accounts SET my_column = 'some_val' WHERE col=my_col_1 and col2=my_col_2 and --etc...

I think:
UPDATE accounts SET my_column = 'some_val', version = my_version+1 WHERE account_id = my_id AND version = my_version;

would work.

also...

where *would* we keep this version attribute?

It doesn't need to be anything complex. An additional column in any tables is probably sufficient. It would probably need an index or clustered index upon it, along with the primary key.

It would be the responsibility of the business object's model to keep track of the version key and verify its integrity (ie it matches what's in the db) when an update (db write) occurs.

Now... as to your possible solution, Srini...

have a couple of columns in the table Sys_creation_Date & Sys_Update_Date

One major hurdle we've come up against is that small tables with fast hardware can actually cause the JDBC writes to appear to be at the same time. Eventhough the db might have the ability to provide the chrono resolution necessary, often JDBC just couldn't keep up.

The versioning (or Optomistic Locking, as Paul put it) has really saved us quite a bit of time and energy.

Good luck!

-daniel

Oliver,

I think that the strictest answer to your question "is [my design] considered thread safe?" is probably, technically, yes. However, that's not to say this is a good, practical OO implementation. I'm no expert, but trying to decypher what's going on in your MyFacade.facadeMethod() is confusing.

I suggest you don't let Servlet implementation details (ie their singleton nature) inhibit your ability to write well-designed objects.

Consider this:

java.lang.Thread.currentThread() returns the current thread.
java.util.Map.put(Object o, Object o) allows you to store any object in a map implementation using any other object as its key in the map.

Now, it is possible using these tools to build a thread-local caching mechanism that will allow you some limited ability to store variables in your servlet in a thread-safe manner. One major gotcha is remembering to pull the myCurrentThread out of the map just before you're leaving your execution scope (ie the Servlet.service(...) method). Consider patterns such as Factory or Observable for implementation details.

Good luck!

-daniel

Tien,

Firstly, the HTML tag <APPLET...> is deprecated in favor of the <OBJECT...> tag; check out this API note for more information.

Secondly, applet code has nothing to do with your servlet / jsp container and conversely, your servlet classpath doesn't provide the client (browser) with the applet. Specifically, the applet should be stored in a place that can be referenced via a URI and you should employ the attributes "codebase" and "archive" to point to the proper location. My guess is (and this is only a guess) that you should store the applet in the same location as the JSP file.

Good luck,

-daniel

Sana,

Another solution might be to save yourself the trouble of having to travel to-and-from the server for each of the steps of your wizard...

Instead, consider using the magic of CSS and DHTML to construct each of the panels of the wizard in a separate <div> container that is hidden/shown upon proper validation of the previous panel...

1. Page loads, shows <div id='first'>
2. User fills out form elements in div#first; clicks [next] button
3. [next] button calls a validate/update function that first verifies the data and then hides div#first and shows div#second.
4. continue for as many panels as necessary.

All of the elements are contained in a single form. The last button ([save]) or whatever can then submit the form.

The primary benefit is not having to perform trips to the server just to break the content up into manageable chunks.

Two biggest downsides are:
1) It requires some work to properly deal with which <div> should be shown when the server detects errors in the form data. This isn't impossible, but it's an issue that has to be addressed.
2) If div#third has form element data that is dependent upon the content provided in div#second, this could be tricky. For example, page one selects continent, page two selects country (based on continent), page three selects state or municipality (based on country), etc.

Good luck!

-daniel

Steve,

It seems that one possibility would be to include a version key in the update. If the version that is supplied in the update is not the same that's in the database (which is updated every commit) then the update would fail, and allow the client to refresh the data...

Something like:

1. User A loads record Foo,v1
2. User B loads record Foo,v1
3. User B makes changes, commits record Foo,v1 which becomes Foo,v2
4. User A attempts to commit Foo,v1 gets a version-out-of-sync error/exception.

This is effectively a non-locked dirty write exception. Instead of the more widely used, "last one to the database wins" this is more of a "first one to the database wins".

Good luck!

-daniel

[DLH: edited for clarity]
[ October 09, 2004: Message edited by: Daniel Hedrick ]

I meant to follow-up on this when I found the information. There are two nice compilations that I came across. They are
http://forum.java.sun.com/thread.jsp?forum=92&thread=208584#788670
and
http://www.waferproject.org/index.html
Wafer looks cool; it's a research project that appears to be dedicated to providing a compare/contrast between lots of open source web app frameworks.
-daniel

Howdy!
I'm trying to find web application frameworks similar to Struts for the purpose of a compare-and-contrast style research project.
Although it appears that most of this forum is directed towards struts-related discussions, I'm hoping that some of y'all can point me toward some resources for finding its competitors.
So, what projects do you know of that work to solve similar problems as Struts? Basically, the whole MVC / Model2 shtick.
Thanks!
-daniel