Thank you for the feeback Ian. I've just sent out the latest rev and replies are inline...
For the "transactional interceptors vs. EJB" topic I now have this diff/change:
< When Transactional annotated managed beans are used in conjunction with EJB container managed transactions the EJB container transaction rules are applied before the interceptor chain is called. Thus the Transactional interceptors may change the transaction context created by the EJB container. It is best practice to avoid such use of Transactional annotations in conjunction with EJB container managed transactions in order to avoid possible confusion.
> See the EJB specification for restrictions on the use of @Transactional with EJBs.
Where the EJB spec will state something to the effect that "It is illegal to annotate an EJB with the @Transactional annotation. Applications should not attempt to do so as the behavior is unspecified and products should detect and fail deployment in this case." Note the "should" language which does not require/"must" the deployment/combination validation.
I've also added mention of TxType.REQUIRED being the default and that method level annotation overrides class level.
I've just remembered I forgot to add the interceptor spec to "related documents" section, darn ;-)
On Mar 18, 2013, at 7:04 PM, Ian Robinson wrote:
> Hi Paul,
> On (1), while I think its OK to choose to remove section 5, if we do this it should have a new section (e.g. like the EJB 3.2 spec) that states something like
> Other Requirements
> The behaviors described in the Javadoc specification of the JTA interfaces are required functionality and must be implemented by compliant providers.
I've added "4.3 Other Requirements" with this verbatim.
>
> Otherwise I don't agree with removing this section.
>
>
> (2) Thanks for that
>
> (3) That conversation was focussed on @PostConstruct - I haven't seen the equivalent discussion or specification of transaction behaviour for @AroundTimeout. The EJB spec, for example, says the following:
> "A timeout callback method on a bean with container-managed transactions must have transaction attribute REQUIRED or REQUIRES_NEW (or Required or RequiresNew if the deployment descriptor is used to specify the transaction attribute). If the container-managed transaction is rolled back, the container retries the timeout.
> Note that the container must start a new transaction if the REQUIRED (Required) transaction
> attribute value is used. This transaction attribute value is allowed so that specification of a transaction attribute for the timeout callback method can be defaulted."
>
> Which spec and section is transactional behaviour defined for @AroundTimeout and other CDI managed bean lifecycle events?
As we've decided to make it illegal to use @Transactional with/on EJB it follows that @AroundTimeout will not be supported. Ie, Transactional interceptors don't need to support @AroundTimeout methods because they'll never see them as those methods are defined only on an EJB. I have removed ""timeout methods" from the line of the spec mentioned:
<The Transactional interceptor interposes on business method invocation, timeout methods, and lifecycle events. It does not interpose on constructor invocations.
>The Transactional interceptor interposes on business method invocation and lifecycle events. Lifecycle methods are invoked in an unspecified transaction context unless the method is annotated explicitly with @Transactional.
As you see I've also added txt for the " lifecycle events"/"constructor invocations" topic/resolution. So if you have any comments on the wording, etc. there do let me know as well.
>
>
> Paul "Let me start a separate thread with CDI folks to resolve this."
> Thanks - that is now CDI https://issues.jboss.org/browse/CDI-355
>
> (4) Paul "Understood, I will make this clarification. I believe this was the rationale, ie not to restrict but to not have a requirement, ie leave it "undefined" as you say."
> Thanks - please can we get a draft that includes this update.
done
< The transaction context must be destroyed after completion call have been made on enlisted resource but before any Synchronization.afterCompletion methods are called.
> The transaction context must be destroyed after completion calls have been made on enlisted resources. Any Synchronization.afterCompletion methods will be invoked in an undefined context.
Again draft is sent to jta user's list.
>
>
> Ian "This section explicitly states that beans with this annotation have contextual references, which excludes components whose lifecycle is managed by a Java EE container (not CDI). What should be the result of annotating such a component with @TransactionScoped? I think we need to discuss what the behaviour is supposed to be and explicitly document it. "
> Paul "This feature is intended for use in CDI only. I'm not sure if that answers your question. Please let me know what clarifications you would suggest if you would."
>
> Something like this.
> The @Transaction annotation states:
> "The javax.transaction.Transactional annotation provides the application
> the ability to declaratively control transaction boundaries on CDI managed beans, as
> well as classes defined as managed beans by the Java EE specification, at both the class
> and method level."
>
> Thats clear. What isn't is @TransactionScoped.
>
> For @TransactionScoped I think we need something like:
> "The javax.transaction.TransactionScoped annotation provides the ability to
> specify a standard CDI scope to define bean instances whose lifecycle is scoped to the
> currently active JTA transaction. This annotation cannot be used by classes defined as managed beans by the Java EE specification, which have non-contextual references."
>
> I'm looking for some clarification along those lines.
done in both spec and javadoc:
< currently active JTA transaction. This annotation cannot be used by classes defined as managed beans by the Java EE specification which have non-contextual references.
> currently active JTA transaction.
>
> (5) Paul: "I still need to make this update and also update the JDBC version in one spot."
done:
> If an attempt to use the UserTransaction is made from within a bean or method annotated with @Transactional, an IllegalStateException must be thrown, however, use of the TransactionSynchronizationRegistry is allowed.
> (6): Paul: "Yes, I will get this as well. I also have the (lifecycle) interceptor topic(s) mentioned and a couple other minor items (like removing "standard extension API" from JDBC and including interceptor spec to the related documents), as well as any further feedback and mods of course."
I think the test assertion comment was removed actually and I've made the mods for the other items I mention.
>
> Thanks. Do we need to extend the PR window? I'd like to review a draft with all the proposed changes in it before IBM signs off on the MDR.
I do apologize for any delays and the last minute issues but extending the PR will definitely complicate things and so getting it done in the short window we have is definitely highly desired at the least. I hope I have gotten the latest to you quickly enough and we do have this as our top priority.
>
> Regards,
> Ian
>
> Ian Robinson, IBM Distinguished Engineer
> WebSphere Foundation Chief Architect
> IBM Hursley, UK
> irobins_at_uk.ibm.com
> Admin Assistant: Janet Brooks - jsbrooks12_at_uk.ibm.com
>
>
>
> From: Paul Parkinson <paul.parkinson_at_oracle.com>
> To: users_at_jta-spec.java.net,
> Cc: Linda DeMichiel <linda.demichiel_at_oracle.com>, Kevin Sutter <sutter_at_us.ibm.com>, Joseph Bergmark <bergmark_at_us.ibm.com>
> Date: 15/03/2013 22:59
> Subject: [jta-spec users] Re: latest rev of spec and diff/comparison file
>
>
>
> Hi Ian,
>
> Thanks for the feedback. Replies inline...
>
> On Mar 14, 2013, at 2:43 PM, Ian Robinson wrote:
>
> Thanks Paul.
> I can now see the public review draft. Unfortunately it doesn't seem to have the changes you said you were going to make. It also seems to have several sections missing and a number of other changes that have not been previously discussed on the JTA mailing list.
>
> 1) The draft is missing Section 5 (API Reference).
> This was removed as it is redundant (and has been inconsistent for versions now) with the actualy JTA API. This is also consistent with many/most other specs which do not include the API in the spec.
>
>
> 2) I see a new entry in Change History "Various update of stale material, version updates, etc." that wasn't in the last version that was shared.
> Please could we get a new document with change bars relative to JTA 1.1 to see what these are.
> Yes, sorry, I neglected to post the latest diff when I posted the spec and javadoc the other week: http://java.net/projects/jta-spec/sources/spec-source-repository/content/jta1.1to1.2diff.pdf?rev=6
> These are all version updates, removal of obsolete material, etc. and not new functionality.
>
> 3) There have been several changes in the text in sections 3.7 that have not been discussed on the mailing list.
>
> For example
> Previous text in section 3.7
> "The javax.transaction.cdi.Transactional annotation provides the application the
> ability to control transaction boundaries on CDI managed beans, as well as
> classes defined as managed beans by the Java EE specification such as
> servlets, JAX-RS resource classes, and JAX-WS service endpoints,
> declaratively. This support is provided via an implementation of CDI
> interceptors that conduct the necessary suspending, resuming, etc. A
> javax.transaction.cdi.TransactionalException with a nested exception is thrown from
> the interceptor as appropriate. The TxType element of the annotation
> indicates whether a bean method is to be executed within a transaction
> context where the values provide the following corresponding behavior:"
>
> New text in section 3.7:
> "The javax.transaction.Transactional annotation provides the application
> the ability to declaratively control transaction boundaries on CDI managed beans, as
> well as classes defined as managed beans by the Java EE specification, at both the
> class and method level. This support is provided via an implementation of CDI
> TRANSACTIONAL ANNOTATION 25
> interceptors that conduct the necessary suspending, resuming, etc. The
> Transactional interceptor interposes on business method invocation, timeout
> methods and lifecycle events. It does not interpose on constructor invocations. The
> Transactional interceptors must have a priority of
> Interceptor.Priority.PLATFORM_BEFORE+200. Refer to the Interceptors
> specification for more details.
> The TxType element of the annotation indicates whether a bean method is to
> be executed within a transaction context where the values provide the following
> corresponding behavior:"
>
>
> - Please can you explain what is meant by "timeout methods and lifecycle events" in this context? This is appearing for the first time in this draft, which surprises me.
> I am referring to the interceptor types (AroundTimeout, AroundInvoke, AroundConstruct). I just deferred tot he interceptor spec on this by saying "Refer to the Interceptors
> specification for more details." as you see in the snippet but I can add a descriptive sentence if you have an idea.
> This is actually the crux of the current "transactional interceptors and lifecycle methods" thread(s) on this list (that you replied to) as well as jsr342-experts_at_javaee-spec.java.net and so is an ongoing (but hopefully concluding soon if not today) open issue. The email has the subject of
> .
> - Also, what is the significance and rationale behind Interceptor.Priority.PLATFORM_BEFORE+200? I didn't see any discussion of that on the mailing list either.
> Priority in general has been on the interceptor and CDI mailing lists and the javadoc can be found here: http://javaee-spec.java.net/nonav/javadocs/index.html?javax/interceptor/Interceptor.Priority.html
> I sent out the/this question to this list on February 4:
> "
> Hello,
>
> Please provide feedback on the assignment of a priority value for the transaction interceptor(s that provides the functionality behind the new Transactional annotation).
>
> This is analogous to the "0" value in/of OTS ;) and the current proposal is to use Interceptor.Priority.PLATFORM_BEFORE+200 (see below).
>
> Again as we are running very short on time prompt feedback is greatly appreciated.
>
> Thanks,
> Paul
> "
> I received one +1 from Redhat/JBoss.
>
> - The specific text around servlets etc has been removed but I think it is still implied by "classes defined as managed beans" - can you clarify?
> I don't recall exactly and couldn't find the reference, sorry ;-) . It does read cleaner and server as a dynamic/catchall rather than a finite listing of examples.
>
> - I believe we need to additionally clarify a potential conflict between JTA and CDI: servlets, JAX-RS resource classes, and JAX-WS service endpoints are created by their containers with non-contextual references (according to the platform specification EE 5.24 and in our implementation) but the CDI spec (section 7.2) precludes bean with non-contextual references from being intercepted:
>
> 7.2. Container invocations and interception
> When the application invokes:
> • a method of a bean via a contextual reference to the bean, as defined in Section 6.5.3, “Contextual reference for a
> bean”, or
> • a business method of a session bean via an EJB remote or local reference,
> the invocation is treated as a business method invocation.
>
> --snip--
>
> If, and only if, an invocation is a business method invocation:
> • it passes through method interceptors and decorators, and
> • in the case of a session bean, it is subject to EJB services such as declarative transaction management, concurrency, se-
> curity and asynchronicity, as defined by the EJB specification.
> Otherwise, the invocation is treated as a normal Java method call and is not intercepted by the container.
>
>
> It seems like CDI 7.2 needs to extend the scope of "business method of a session bean via an EJB remote or local reference" to include @Transactional beans with non-contextual references. Can you confirm whether this interpretation is correct and, if so, how the CDI spec could be changed to be consistent?
> Let me start a separate thread with CDI folks to resolve this.
>
> 4) There have been several changes in the text in sections 3.8 that have not been discussed on the mailing list.
>
> For example
>
> - "The transaction context must be destroyed after completion call have been made on enlisted resource but before any Synchronization.afterCompletion methods are called."
>
> This is new and hasn't been discussed on the mailing list before. Why would the spec place a new contraint on implementation of transaction context lifecycle in this section? Other parts of the specific describe the context in afterCompletion as "undefined" (e.g. registerInterposedSynchronization: The afterCompletion callback will be invoked in an undefined context.). I disagree with introducing this constraint as stated - its an implementation detail. I agree with the intent which is to say that transactionScoped object should not be available in afterCompletion. The previously shared draft of the spec implied this without using this text.
> Understood, I will make this clarification. I believe this was the rationale, ie not to restrict but to not have a requirement, ie leave it "undefined" as you say.
>
> - This section explicitly states that beans with this annotation have contextual references, which excludes components whose lifecycle is managed by a Java EE container (not CDI). What should be the result of annotating such a component with @TransactionScoped? I think we need to discuss what the behaviour is supposed to be and explicitly document it.
>
> This feature is intended for use in CDI only. I'm not sure if that answers your question. Please let me know what clarifications you would suggest if you would.
>
> 5) This draft still states Use of UserTransaction from within a method or bean annotated with @Transactional is not restricted.
> I had understood ("I'll update the spec and let you know... ") we were going back to
> " If an attempt to use the UserTransaction is made from within a bean or method annotated with @Transactional an IllegalStateException must be thrown."
> with the use of TransactionSynchronizationRegistry being unrestricted.
> Yes, sorry, I still need to make this update and also update the JDBC version in one spot.
>
> 6) We had agreed the following text would be reomved but it is still present:
> Transaction transaction = transactionManager.suspend(); //tx1 suspended
> //assert testTxAssociationChangeBean still associated with tx1 and
> // that no transaction scope is active.
> Ian: How? Shouldn't I get ContextNotActiveException if I try to use testTxAssociationChangeBean?
>
> Paul: I meant this as an internal/implementation assertion but I do see that this is confusing and it also makes it impossible to put actual portable assertion code in the spec and so I've simply removed it. An assertion for the ContextNotActiveException case already exists later in the example.
>
> This code is still in the PR draft.
>
> Yes, I will get this as well. I also have the (lifecycle) interceptor topic(s) mentioned and a couple other minor items (like removing "standard extension API" from JDBC and including interceptor spec to the related documents), as well as any further feedback and mods of course.
>
>
>
>
> Regards,
> Ian
>
>
>
>
>
> From: Paul Parkinson <paul.parkinson_at_oracle.com>
> To: users_at_jta-spec.java.net,
> Cc: Linda DeMichiel <linda.demichiel_at_oracle.com>, Kevin Sutter <sutter_at_us.ibm.com>
> Date: 09/03/2013 18:39
> Subject: [jta-spec users] Re: latest rev of spec and diff/comparison file
>
>
>
>
>
> Hi Ian,
>
> Extremely sorry for that. I will post the spec and send an email to this list now.
> (I had originally thought the latest was at http://jcp.org/aboutJava/communityprocess/maintenance/jsr907/index5.html)
>
> Thanks,
> Paul
>
> On Mar 9, 2013, at 10:20 AM, Ian Robinson wrote:
>
> Thanks Paul. On the mechanics of "I'll update the spec and let you know...", I'm bothered that a MDR5 was started on Feb 28 without any notice to this distribution (I only just found out that it started a week before your attached mail) and the public review materials at http://jcp.org/aboutJava/communityprocess/maintenance/jsr907/907ChangeLog.html
> are just the 3 JIRAs - not the currently proposed concrete changes to the specification. Am I looking in the wrong place? I'm not sure how to proceed on an MDR that closes on April 1st without having seen a concrete spec to vote on.
>
> There is a further clarification I'd like around @Transactional but I'll put that in a separate mail to this distribution.
>
> Regards,
> Ian
>
>
>
>
>
> From: Paul Parkinson <paul.parkinson_at_oracle.com>
> To: Ian Robinson/UK/IBM_at_IBMGB,
> Cc: Linda DeMichiel <linda.demichiel_at_oracle.com>, users_at_jta-spec.java.net
> Date: 05/03/2013 19:59
> Subject: Re: [jta-spec users] latest rev of spec and diff/comparison file
>
>
>
> Hi Ian,
>
> Sorry, I just meant that Linda and I had a talk on it and likewise others internally have since mentioned using/allowing TransactionSynchronizationRegistry instead. Eg, I had sent this: "maybe we disallow UserTransaction and allow TransactionSynchronizationRegistry usage instead. TransactionSynchronizationRegistry does have setRollbackOnly and getTransactionStatus but does not have setTransactionTimeout."
>
> So I think what you mention sounds like a good idea unless Linda or anyone else sees an issue. I'll update the spec and let you know...
>
> Thanks,
> Paul
>
> On Mar 5, 2013, at 2:13 PM, Ian Robinson wrote:
>
> > We'd actually had a discussion around 2 and were thinking of using this instead (hopefully the spec line itself explains the rationale):
>
> Hi Paul, I'm a little confused - where did we have that discussion? The last discussion I saw made sense whereas I don't think this does: allowing access to UserTransaction with caveats that aren't enforced ("...the application must ensure the UserTransaction is not used in a way that will compromise the behavior of any transaction..."). JTA has been a solid spec for a long time, including its integration with EJB, because we don't let applications undermine the integrity of managed transactions. The good news is that we already have the TransactionSynchronizationRegistry interface for this kind of use and it should be fine to allow access to that, as that interface is designed to offer no UOW control operations. But UserTransaction should not be available to a method annotated with @Transactional
>
> Regards,
> Ian
>
>
>
>
>
> From: Paul Parkinson <paul.parkinson_at_oracle.com>
> To: Ian Robinson/UK/IBM_at_IBMGB,
> Cc: users_at_jta-spec.java.net, Linda DeMichiel <linda.demichiel_at_oracle.com>
> Date: 25/02/2013 21:01
> Subject: Re: [jta-spec users] latest rev of spec and diff/comparison file
>
>
>
> Thanks Ian. We'd actually had a discussion around 2 and were thinking of using this instead (hopefully the spec line itself explains the rationale):
>
> "Use of the UserTransaction from within a method or bean annotated with @Transactional is not restricted. For example, the UserTransaction may be needed in these cases to mark the transaction for rollback or obtain the status of a current transaction. However, the application must ensure the UserTransaction is not used in a way that will compromise the behavior of any transaction that may be managed by the container. In particular, UserTransaction should not be used to commit or rollback a transaction that was started by a transaction interceptor, as such an action might compromise the integrity of the application."
>
> Regards,
> Paul
>
> On Feb 25, 2013, at 3:55 PM, Ian Robinson wrote:
>
> Thanks Paul - these look good for #2 and #3.
>
> Regards,
> Ian
>
>
>
>
>
> From: Paul Parkinson <paul.parkinson_at_oracle.com>
> To: Ian Robinson/UK/IBM_at_IBMGB,
> Cc: users_at_jta-spec.java.net
> Date: 25/02/2013 17:04
> Subject: Re: [jta-spec users] latest rev of spec and diff/comparison file
>
>
>
> Hello Ian, replies on 2 and 3 inline...
>
> On Feb 16, 2013, at 12:56 PM, Ian Robinson wrote:
>
> Paul,
>
> I have 3 concerns around the proposed new sections 3.7 and 3.8.
>
> #1
> My earlier comments/concerns about EJB/CDI behaviour remain and haven't been resolved. This is detailed in the comments of the Jira feature:
> http://java.net/jira/browse/JTA_SPEC-5
>
> As suggested in the jira, I prefer something like:
> In the spirit of not requiring the deployment process to detect and prevent, could I suggest something like:
> "When Transactional annotated managed beans are used in conjunction with EJB container managed transactions the EJB container behavior is unspecified and not portable. Valid container implementations include, but are not limited to:
> the bean may fail to deploy
> the Transactional annotation may be ignored
> the EJB container behavior is applied before the bean is called. When the bean is called the CDI behavior is applied before calling the bean's methods.
> It is best practice to avoid such use of Transactional annotations in conjunction with EJB container managed transactions in order to avoid possible confusion. and lack of portability."
>
>
> I listed some examples in the jira of why I believe we need this. The text above allows the behaviour currently stated in the spec but also allows alternative behaviours. This is an edge case that the spec recommends avoiding but unless we provide flexibility along the these lines, we need to go through the "awkward" cases I enumerated (and any others we can think of - those were just a few that came to mind) and tighten up the spec. I think we're better off with more flexible container behaviour.
>
> #2
>
> In your mail below you say
> - perhaps explicitly mention that while UserTransaction should not be used inside a Transactional CMT, unlike EJB, use will not actually be restricted
>
> I'd assumed the opposite so I agree we need to explicitly document something. I think it needs to be an exception in the same way it is for EJB CMT. If the container is managing the transaction then the management is compromised by having the bean able to manipulate it.
>
>
> I've added the following in 3.1:
> " If an attempt to use the UserTransaction is made from within a bean or method annotated with @Transactional an IllegalStateException must be thrown."
>
> #3
>
> Section 3.8 says:
> "The javax.transaction.cdi.TransactionScoped annotation provides the ability to
> specify a standard scope to define beans whose lifecycle are scoped to the currently
> active JTA transaction. The transaction scope is active when the return from a call to
> UserTransaction.getStatus or TransactionManager.getStatus is one ofthe following
> states:
> Status.STATUS_ACTIVE
> Status.STATUS_MARKED_ROLLBACK
> Status.STATUS_PREPARED
> Status.STATUS_UNKNOWN
> Status.STATUS_PREPARING
> Status.STATUS_COMMITTING
> Status.STATUS_ROLLING_BACK
> ...
> A javax.enterprise.context.ContextNotActiveException must be thrown if an object
> with this annotation is used when the transaction context is not active.The object with
> this annotation is associated with the JTA transaction where it is first used and this
> association is retained through any transaction suspend or resume calls as well as
> any beforeCompletion Synchronization calls until the transaction is completed."
>
>
> I interpret this as requiring a ContextNotActiveException to be thrown if the TransactionScoped object is used while the transaction with which it is associated is suspended from the thread on which the object is used. Is that correct?
>
> But then the psuedocode example says:
> Transaction transaction = transactionManager.suspend(); //tx1 suspended
> //assert testTxAssociationChangeBean still associated with tx1 and
> // that no transaction scope is active.
>
> How? Shouldn't I get ContextNotActiveException if I try to use testTxAssociationChangeBean?
>
> I meant this as an internal/implementation assertion but I do see that this is confusing and it also makes it impossible to put actual portable assertion code in the spec and so I've simply removed it. An assertion for the ContextNotActiveException case already exists later in the example.
>
>
>
> Regards,
> Ian
>
>
>
>
>
> From: Paul Parkinson <paul.parkinson_at_oracle.com>
> To: users_at_jta-spec.java.net,
> Date: 04/02/2013 16:20
> Subject: [jta-spec users] latest rev of spec and diff/comparison file
>
>
>
>
>
>
>
> Hello,
>
> The latest rev of the spec can be found here: http://java.net/projects/jta-spec/sources/spec-source-repository/content/jta-1_2-spec_v2.pdf?rev=4
> along with the diff/comparison file here: http://java.net/projects/jta-spec/sources/spec-source-repository/content/jta1.1-to-1.2comparison.pdf?rev=4
>
> A few items I still need to address:
> - fix/add links
> - add CDI in "relationship to other java APIs" and reference sections
> - perhaps explicitly mention that while UserTransaction should not be used inside a Transactional CMT, unlike EJB, use will not actually be restricted
> - etc. ;)
>
> As always feedback is greatly appreciated as we try to close this down for final JTA 1.2.
>
> Thanks,
> Paul
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU