Win a copy of Head First Android this week in the Android forum!

Dean Pullen

Ranch Hand
+ Follow
since May 30, 2003
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 Dean Pullen

Hi all,

I'm trying to implement an immutable class, and am using the static builder pattern as defined in Effective Java.


This is a usual pattern I follow. However, I'm constrained by a third party system that requires an instance of the object to be initialised via a no-args public constructor.
It will then be 'properly' initialised by a (non-static) builder at the appropriate place.

What do people think of allowing this? It seems dirty but can't quite put my finger on how dirty!



8 years ago
An old one but found via google when I was searching for the same thing.

I hadn't declared my aspect as a bean within the config file (or used @Component) so it wasn't scanned.

However, you appear to have missed @Aspect at the top of your Audience class.

public class Audience { .. }
I'm pretty sure this is more relevent to EJB3 than JDBC...

It's a Java object containing other Java objects, detached from the database. Thus it's a 'Java cache', whatever you mean by that?
Hi all.

I can't quite get my head around what can happen with data during (and after) a transaction.
Any advice (or reading material), as always, would be appreciated.

[Using JBoss 4.2.3 with EJB3/Hibernate JPA].

If during a transaction, we refresh a cache of data from the DB which we've added a value to during the transaction (thus it's not actually persisted yet, but 'available' within the transaction) but this data is also refreshed in another concurrent thread, what is the final outcome of the cache data?

Is it
a) the transaction's update and subsequent refresh from the DB, ignoring the other thread's update
b) the other thread's update, removing the transaction's changes
c) due to the 'isolation' in ACID, the data that's 'touched' within the cache class cannot be edited until the transaction is complete (the other thread is locked until the transaction is copleted)
d) something else

I'm hoping, and believe from the EJB spec, that it's c) but I just want a little clarification.

Many thanks...

Btw is this more suited to a different forum, say the EJB one?
Hi all,

Posted this on the JBoss forums but not got any kind of response.

We're seeing an underlying timeout and transparent authentication problem, that we simply don't understand.

User logs in
Uploads a file ~takes >10 mins
Uploads a file ~takes >10 mins
Uploads a file ~takes >10 mins

During this last upload we see the user (in the logs) being re-logged in, but no login screen has been shown to the user.

What is causing this timeout, when they've been performing the above task during the session? Surely session time-out etc is based on idle time?

It wouldn't be a problem, but we're comitting to the DB within the login module which causes any current managed transaction to fail.

Preferably I'd like to understand what's going on, and how within the login module, we can detect this underlying re-login (so as not to perform the user login date/time commit which causes the problem).



12 years ago
Ok thanks for the suggestions - all interesting reading.
12 years ago
Either you're not using a 5.x JDK or you need to configure Tomcat to use JDK 5 extensions.

Edit your TOMCAT_INSTALL\conf\web.xml. Add to the org.apache.jasper.servlet.JspServlet the following lines:

12 years ago
Took me a few glances to understand what you meant, but you're basically saying to:

a) Hold a Map in memory key'd by a unique ID that is the unique ID of an element within the (in-memory) DB

b) Utilise the DB to find the ID, then retrieve from the Map

Aren't you now holding the information in both the map and the DB, thus doubling (well, increasing) memory requirements?
12 years ago
Tbh it's pretty easy to find information on static usage on the web, via Google.

And the Sun Java tutorial:

Static members are class members, not class instance members.
So there's one 'instance' of each static member for any number of class instances.

I think that tutorial page above does a pretty good job of explaining it, and even has a very basic example.
12 years ago
Bill's point about the single key - I hadn't even thought of it. *smacks head*

However, sometimes we want all objects that match a certain part of the (ultimately) unique key.

E.g. all objects with a certain year and month, but not specifying 'code' and 'someothercode'.

How would you then get these specific objects from the Map?

12 years ago
Thanks for the replies so far.

Hm the HSQLDB option sounds interesting, I'd not thought/heard of utilising it in that matter.

I also thought of using something like JBoss Cache or similar, but haven't read too much into it. Though I suspect this wouldn't really get around the data structure problem that's already inherent.
12 years ago

Pretty sure this is intermediate level too, but would prefer more of the advanced peeps to give some feedback.

I have an application that needs in-memory access to a lot of data. Basically this data is a large (10k's) of EJB3 entities, which are, as you know, just POJOs.

So in essence we just have a large collection of POJOs.

Each of these needs to be accessed quickly given a set of params. E.g. Month, Year, Code, Some Other Code.

So I've plumped them all in a large Map for very quick retrieval.

i.e. myObject = map.get(month).get(year).get(code).get(someOtherCode);

Obviously this becomes a bit of a mess putting this data in the Map, keeping it up-to-date, and it looks pretty awful.
It works very well. Everything is in-memory and very fast. It just doesn't look and feel right.

What's a more OO way of doing this? Any suggestions on a better alternative which isn't so cumbersome?

I'd appreciate your feedback and idea.


12 years ago
Indeed the tomcat 'SSO' valve is exactly what we use between web apps on the same server.
For example, we have a standard war for portlets on JBoss Portal and a non-portlet war which we use for some AJAX requests and a variety of portlet 'unallowed' requests.

This needs the valve configured for SSO.
This is a very very common error when you're trying to use multiple datasources within Jboss 4.

You'll almost certainly find the answer instantly on a google.

Basically, it sounds like you're trying to use more than one datasource in the same transaction.

There's a simple way of getting around this - extrapolate the procedure that deals with the second datasource and use the @NewTransaction annotation to ensure a new transaction is started for the use of the second datasource.

You can read more here (including other methods of getting around this):

12 years ago