[ http://issues.apache.org/jira/browse/DAYTRADER-14?page=comments#action_12443523 ] Matt Hogstrom commented on DAYTRADER-14: ----------------------------------------
The challenge as you pointed out is to somehow invalidate the KeySequence SLSBs. Since their most likely pooled it makes it a bit more tricky. The simplest way to do this which is non-standard would be to use a static int or some other fingerprint on the integrity of the tables. However, this doesn't help the situation when your running a cluster of the application so its applicability would be really to a single server. One possibility is to put in a timestamp as static that indicates the last time the table was valid. Then, for each SLSB keep a last used time and compare the two. If the last used is less than the valid then the beans need to be refreshed so all values could be reset at that time. The easiest solution I think is to allow the tables to be created...if they already exist warn the user that they need to recycle their environment. I'd be happy with that solution as its way better than what we have. If someone is repopulating...they should be fine with recycling. If possible, I'd add some text when a duplicate key exception occurs that would tip off the user of the possible problem with the Key entity. > Include sql script in the ear and use a gbean to create tables etc > ------------------------------------------------------------------ > > Key: DAYTRADER-14 > URL: http://issues.apache.org/jira/browse/DAYTRADER-14 > Project: DayTrader > Issue Type: Improvement > Components: EJB Tier > Affects Versions: 1.2 > Reporter: David Jencks > Attachments: d-j-plan.xml, DAYTRADER-14.patch > > > You can use the DatabaseIntitializationGBean (GERONIMO-2396) in a g. plan and > include the sql script in the ejb module so the database will get created if > not already present. This is way better than the previous hack of including a > pre-built database in the car file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira