|
Sorry if this is long winded.
In a long transaction in the web environment we
load our objects, copy some fields into the web page and exit. When the post
returns we copy those fields back into new objects and try to db.update but
can't because the timestamp is wrong, so we have to reload the objects from the
cache and copy the fields over to these objects.
In a layered application this results in two copies
because the web layer would do the copy from the web fields to the domain data
objects, these would then pass through the business layer to the data access
layer where a second copy has to occur to get the fields into the objects with
the correct timestamp in them.
My current solution is to only copy the timestamp
into my new objects and I know this is bad because the object may already be
dirty but I am still testing so don't care. Hence, I am pondering the final
implementation.
The next better solution suggested in an earlier
post was to store the object itself in the web layer in session cache but this
results in more cache management code and lots of memory wasted when all you
really need is the timestamp.
The next alternative mentioned in an earlier post
was just to get the timestamp out and put into the web page with all the other
fields being shuffled up to the browser and back again.
The thread is about how best to do this. If the
get/setPrimaryKey methods in the objects returned the timestamp along with the
actual key this whole process would be transparent. Key and timestamp
would moved up to the browser and back down into the object and the update
would work.
The caster mappings file would contains the
get/setPrimaryKey methods but the application classes would use the
get/setPrimaryKeyLongTx methods. Its like the object would have two interface,
one to the application and another to the database.
Of course, this would have to be done for all your
key getters methods, getUserNameLongTx or getSSNLongTx etc and I am not sure how
this would pan out over a large object domain.
----- Original Message -----
Sent: Wednesday, June 18, 2003 4:10
PM
Subject: Re: [castor-dev] Timestamp/Key
idea
This one time, at band camp, Edward Sumerfield
said:
ES>RE: [castor-dev] [JDO] bug 1107 Timestamp mismatched
exception when using longtransactionI haven't implemented this but was
thinking I might try it. Anyone think it would help?
ES>
ES>All
the getKey methods in your castor classes should have a corresponding
getKeyLongTx that returns the actual key value concatenated with the
jdoTimestamp. The corresponding setKeyLongTx would split the values and store
them appropriatly back into the original object.
ES>
ES>class
Person implements TimeStampable
ES>{
ES> private
long m_timeStamp = 0;
ES> private long int
m_key;
ES>
ES>
ES> public String
getPrimaryKeyLongTx()
ES>
{
ES> StringBuffer
primaryKeyLongTx = new
StringBuffer();
ES>
primaryKeyLongTx.append(String.valueOf(jdoGetTimeStamp()));
ES>
primaryKeyLongTx.append("|");
ES>
primaryKeyLongTx.append(String.valueOf(getPrimaryKey()));
ES>
return primaryKeyLongTx.toString();
ES>
}
ES>
ES> public void setPrimaryKeyLongTx(String
a_primaryKeyLongTx)
ES>
{
ES> int barPos =
a_primaryKeyLongTx.indexOf('|');
ES>
String timestamp = a_primaryKeyLongTx.substring(0,
barPos);
ES> String primaryKey
= a_primaryKeyLongTx.substring(barPos +
1);
ES>
jdoSetTimeStamp(Integer.parseInt(timestamp));
ES>
setPrimaryKey(Integer.parseInt(primaryKey));
ES>
}
ES>
ES> public void jdoSetTimeStamp(long
a_timeStamp)
ES>
{
ES> m_timeStamp =
a_timeStamp;
ES>
}
ES>
ES> public long
jdoGetTimeStamp()
ES>
{
ES> return
m_timeStamp;
ES>
}
ES>
ES> public int
getPrimaryKey()
ES>
{
ES> return
m_key;
ES> }
ES>
ES>
public void setPrimaryKey(int a_key)
ES>
{
ES> m_key =
a_key);
ES> }
ES>}
Ed,
When and
where would this be used? Please explain the idea behind this, I'm a
bit
slow today as I'm not feeling well.
On a side note, I want to speak to
you about your post here:
http://www.brainopolis.com/castorwiki/Wiki.jsp?page=CastorCommonsLogging
I
am actually in the process of refactoring Castor's logging mechanism.
I
tried using the class posted in the Wiki but did not receive the
expected
log statements.
At this point I'm torn between whether to
make use of Jakarta Commons Logging
or just straight Log4J. The Commons
Logging would be nice to implement from a
user perspective because users
can choose the logging mechanism that is used.
However, the following
article seems to indicate that things as simple as
changing the logging
threshold are impossible:
http://www.zdnet.com.au/builder/program/java/story/0,2000034779,20272367,00.htm
But
the article does indicate that this type of configuration changes
should be
handled via the application that's using the logging.
So I'm torn here.
What's your opinion?
Bruce
--
perl -e 'print
unpack("u30","<0G)[EMAIL PROTECTED]&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject
of:
unsubscribe
castor-dev
| 