Imagine these classes where SeasonPoints is aggregated by composition to Team and Season, where a Team that plays in many Seasons can have multiple SeasonPoints, and a Season with many Teams can have multiple SeasonPoints from different Teams.
Note that in order for SeasonPoints to exist it needs a team that scored points and a season that the points were scored at, so i don't see other way of making this diagram:
1 n n 1
|Team|<comp>----|SeasonPoints|-----<comp>|Season|
The question surges because this way you could destroy either Team or Season and SeasonPoints would still exist (in the other class that wasn't destroyed), which would mean that a container could be destroyed without destroying the class that it contains, and composition says that if the container is destroyed so should the contained classes.
Here is what the specs say:
Sometimes a Property is used to model circumstances in which one instance is used to group together a set of instances; this is called aggregation. To represent such circumstances, a Property has an aggregation property, of type AggregationKind; the instance representing the whole group is classified by the owner of the Property, and the instances representing the grouped individuals are classified by the type of the Property. AggregationKind is an enumeration with the following literal values:
none: Indicates that the Property has no aggregation semantics.
shared: Indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.
composite: Indicates that the Property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects (see the definition of parts in 11.2.3).
Composite aggregation is a strong form of aggregation that requires a part object be included in at most one composite object at a time. If a composite object is deleted, all of its part instances that are objects are deleted with it.
So basically your model is simply wrong (according to the last sentence).
But - Better you forget about aggregation since they introduce more fuzz than they actually add semantics. There are so many discussions about this. Is a car composed of wheels as even the above specs shows it in examples? You know, that a wheel can live on its own and is not "destroyed" when the car is destroyed. When you model a database, this can be useful (delete depending information) or when you have to model memory (free space for composite elements). But in almost all cases a simple association with multiplicity is enough information.