Yuval Goldstein

+ Follow
since Dec 27, 2006
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Yuval Goldstein

- If you are receiving a lot of result try setting the result fetch size to a large number.

- Consider consolidating queries
- Consider executing queries from a stored procedure
- Consider pre-fetching some of the information before the time you actually use it
- Consider using application level caching.

14 years ago
It seems you compiled your code with a different JDK version than the one you are using to run the code with.

In your application server startup script put something like "ECHO %JAVA_HOME%" to see which jdk you are using.

14 years ago
Thats a good idea, many use it.

Also, I use to keep enum values inside my exception and when passing arguments to the exception construction I pass a value which is one of the enum value.
If you are on this issue I have couple of more improvements: use the enum value as a key for a message bundle message to your log or even show it to the user.
Further more, if the exception translated to an error shown to the user on the presentation level and you want to be able to trace it back to your logs, you can generate a numeric id and tell the user something like:
"If you wish to contact our support-> this is the error number you received".
The other part here, is that you need to log this down or write the error details in the database so they can be used later on by the support.
This is useful in login/password flows.

14 years ago
I'm not I understand you completely, however you may find the folloeing information useful:

When you have a servlet class, there is actually only a single servlet object instance in memory (you don't control that, this is performed by the servlet container).

So, if declare a class member in this servlet class, then each user activating a web request is using the same actual object, which is almost always not recommended.

If you want to make sure no user is 'stepping over' another users objects make sure you create local method variables and do the whole 'user specific request' with these objects.
Otherwise, your objects are not thread safe.

As an exercise, you can try printing the objects's hashcode in each request. If it is the same hashcode, then it's not thread safe.

14 years ago
What isolation strategy are you using (on connection and database level?)

Also what kind of locking do you monitor at the database during the deadlock (row, table, page?)

Hi Guys,
Its true you can use LOBS but actually there are some considerations not to keep the documents at the database at all but to keep them on the file-system.
If you require access to these files form several servers, you will not to store them on some storage that is available on the network (NFS, SAN, NAS)

- Inserting and reading large BLOBS (more that several MBs) suffer from low performance, sometime even horrible performance.
- The file system is already a sort of a database. It has an hierarchial structure to keep files and it is build for file access. In many cases you will want to search or access files according to their directory tree ( /users/documents/word/my.doc ).
- If you would like users to download these files, it is best you have in a 'download ready state', without having to read them by code and send them as bytes over some servlet.
- You cant look at files content when they are in the database, sometimes, this is an issue.

Many content management software solutions keep files on the file-system and file meta-data in the database (such as the file-name, author, upload time and such).

When you request a JSP, the server renders html according to your JSP code, this happens before the result is sent to your browser.

When the result html reach your browser, the browser may execute Javascript code according to events. This happens on your desktop client machine.

So, unless you are talking about explicitly running serverside javascript code (that really has nothing related to controlling display elements / dom), the answer is no: JSP runs on the server before, then Javascript may run on the client.
15 years ago
Things get a bit more complicated if you perform a write, rely on some database trigger to update/insert more information and then read this information in the same transactions.

Yes, i guess triggers are evil...
First tried it on the connection level and it didnt work.
Then changed the database default behavior and it works.
Also fixed some scope_ident issues.

Thank a million.
BEA only released EJB 3 Support about a month ago.
JBoss did it a while ago but their EJB GA version is no more than 3 monnths old i think (the version that they say the recommend for production use).
IBM Websphere 6.1 with EJB? Only several months old.

If youre starting a 2 year (calendar time) project, go ahead, the technolcogy will be ok when the time for production comes but if your starting a tight 6 month project today, I recommend doing it the hibernate way,

I had (and still having) my own share of scary bleeding edge near-GA java products and i prefer to take it more slowly this time,
Hey, there is another thing.
I would'nt hurry to mix presentation tier code (servlets, jsps, viewhandlers) with the entity-manager.
You can create and abstraction and decouple "data fetching" and "showing data".

Personally, I think we should still have some patience with EJB 3 implementations. Most major vendor offer them, but it is still a rather new technology. I think that once we see one or two service packs for tje first GA EJB3 version we can start take this option seriously.

Im not always in favor of taking the cautious path but in this case I think you can enjoy most EJB3 features with plain old Hibernate (and Spring).

If you do take the EJB3 path, make sure you have a strong commitment and support from your application-server vendor representatives. You will need it.

You have another thing to consider.

The getter/setter option seem very tempting because you have the chance to manipulate the values of memebers before you return them.
However, If you have validation codein the setter methods, you may encounter a situation during the development, in which you read several records from the database , one record does not match the setter validation rules, the set method fails (hibernate use it to populate the object with data from a db record) and the whole read query fails.

This may also happen if you have a bug and the data in the database is corrupted (does not match the validation rules), you usually wouldn't want to fail the whole 'get many records' action because of one corrupted record.

Anyways, you candecide otherwise but this is the trade-off.

The Session object should only by used by a single Thread.
You usually (99% of the time) open/get a session with each user request and close is when its over.

This is from the javadocs(http://www.hibernate.org/hib_docs/v3/api/org/hibernate/Session.html):

It is not intended that implementors be threadsafe. Instead each thread/transaction should obtain its own instance from a SessionFactory.

We had a look over there.
We see a simple insert query that performs an exclusive lock. But, we have never used xlock in our sql/hql syntax or other locking hints beside nolock.
The inserts look painfully straight-forward.

We have tried similar load of the same query as a database script and we cant seem to reproduce it but when we run our java integration testing code that uses hibernate and spring (but no jboss or JTA), the problem show up again.

We also tried using several isolation level (on hibernate.connection.isolation) and didnt see any change.

Any possibility it may a driver issue (did someone try the jtds driver for sql 2005?) ?

Any ideas?